OUOIEY  KNOX  LIBRARY 
NAVAL  POSTGRADUATE  SCH 
MONTFREY  CA  93943-5101 


Dynamics  of  Naval  Ship  Design:  A  Systems  Approach 


by 
Thomas  A.  Laverghetta 

I! 

BS  Mathematics 
United  States  Naval  Academy,  1990 

SUBMITTED  TO  THE  DEPARTMENT  OF  OCEAN  ENGINEERING 
IN  PARTIAL  FULFILLMENT  OF  THE  REQUIREMENTS  FOR  THE  DEGREES  OF 

NAVAL  ENGINEER 

AND 

MASTER  OF  SCIENCE  IN  OCEAN  SYSTEMS  MANAGEMENT 

AT  THE 
MASSACHUSETTS  INSTITUTE  OF  TECHNOLOGY 

JUNE  1998 


©  1998  Thomas  Laverghetta,  All  Rights  Reserved 

The  Author  hereby  grants  to  MIT  permission  to  reproduce 

and  to  distribute  publicly  paper  and  electronic 

copies  of  this  thesis  document  in  whole  or  in  part. 


DUDLEY  I 
NAVAI 
Dynamics  of  Naval  Ship  Design:  A  Systems  Approach 

by 

Thomas  A.  Laverghetta 

Submitted  to  the  Department  of  Ocean  Engineering 

on  May  18.  1998  in  Partial  Fulfillment  of  the  Requirements  for  the  Degrees  of 

Naval  Engineer  and  Master  of  Science  in  Ocean  Systems  Management 

ABSTRACT 

The  1990  Naval  Sea  Systems  Command  Ship  Design,  Acquisition  and  Construction  (DAC)  Study  provides  a 
stepping  stone  for  the  implementation  of  improvements  towards  optimizing  ship  performance,  cutting  acquisition 
costs,  and  reducing  design  cycle  time.  With  respect  to  performance,  significant  advances  in  computing  power 
coupled  with  customer  oriented  design  (QFD,  AHP.  evolutionary  optimization,  etc)  provide  both  improvements  and 
direct  means  to  measure  effectiveness  of  improvements.  As  for  cost,  implementation  of  world  class  building  and 
design  techniques  (concurrent  engineering,  group  technology.  CAD/CAM/CAE.  etc)  coupled  with  higher  fidelity 
costing  methods  ( ACEIT.  POD  AC.  etc)  provide  savings  and  direct  measures  of  effectiveness.  Cycle  time 
improvements  have  also  been  implemented  (IPTs.  Open  System  Architecture,  3-D  Product  Models,  etc).  However, 
ship  design  managers  have  been  unable  to  identify  and  quantify'  design  process  effectiveness  with  respect  to  the 
impact  of  those  proposed  cycle  time  improvements. 

In  order  to  understand  the  impact  of  cycle  time  improvements,  it  is  necessary  to  examine  the  mechanisms 
which  have  lead  to  increased  cycle  time  including  external  influences  (such  as  increasmg  technological  complexity 
and  budgetary  pressures),  internal  process  delays  (information  flow  delays  and  approval  delays)  and  feedback 
processes  (design  iteration,  error  propagation  and  design  change.)  Modeling  of  such  mechanisms,  using  the 
methods  of  System  Dynamics,  provides  a  means  to  study  past  programs  (in  particular,  the  DDG-51  Destroyer 
program  of  the  1980s),  and  to  study  the  anticipated  savings  that  can  be  generated  with  the  introduction  of  process 
improvements. 

Of  particular  interest  in  modeling  the  naval  ship  design  process  with  System  Dynamics  is  the  flow  of  design 
information.  Traditional  process  analysis  methods  based  on  the  design  spiral  represent  the  progression  of  design 
tasks  as  a  linear  process.  However,  actual  design  data  propagation  (a  fundamental  property  resulting  from  the 
physical  and  architectural  relationships  of  total  ship  systems)  shows  the  process  to  be  highly  non-linear.  These  non- 
linearities  are  captured  by  system  dynamics,  providing  a  simulation  tool  that  more  fully  captures  the  impacts  of 
process  improvements  as  they  relate  to  the  naval  ship  design  process. 
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1       Problem  Statement 

In  June  1990.  under  the  direction  of  Naval  Sea  Systems  Command  (NAVSEA)  Chief  Engineer.  RADM 
Roger  Home,  the  United  States  Navy  undertook  a  program  to  assess  the  effectiveness  of  the  naval  ship  design, 
acquisition  and  construction  (DAC)  process.  The  focus  of  this  project  was  "to  identify  the  critical  actions  necessary 
to  improve  the  quality  of  future  ship  designs  (i.e.  meeting  customer's  performance  requirements),  to  reduce  ship 
costs  (from  research  and  development  through  disposal),  and  to  reduce  the  cycle  time  required  from  establishment  of 
requirements  to  delivery  of  the  lead  ship  ."'  It  was  immediately  recognized  that  naval  ship  acquisition  is  itself 
unique  within  the  constrained  framework  of  the  Department  of  Defense  (DOD)  and  Department  of  the  Navy  (DON) 
organization.  In  particular.  Navy  ships  are  bought  in  small  quantities,  have  very  long  development  cycles,  and  are 
extremely  costly. .  precluding  the  "fly  before  you  buy"  approaches  required  for  purchase  of  other  weapon  systems.2 
Additionally,  the  technical  complexity  of  warship  design  has  passed  the  point  that  any  "one"  individual  can  be  an 
"expert"  in  all  aspects  of  the  design.3  The  resulting  process  is  neither  well  documented  nor  well  understood. 

Although  the  purpose  for  the  DAC  program  was  very  wide-ranging,  the  specific  reasons  prompting  the  DAC 
effort  were  clear:  increasing  naval  performance  requirements  are  resulting  in  increasing  ship  costs  and  increasing 
cycle  times  for  delivery.  The  resulting  "Affordability  Crisis"4  put  strong  pressure  on  the  DOD  to  reform  the 
acquisition  process.  This  "Crisis"  is  analyzed  by  examining  three  key  symptoms:  mcreasing  design  cycle  time, 
constraints  leading  to  sub-optimal  system  performance,  and  increasing  cost  trends. 

1.1       "Affordability  Crisis" 
1.1.1      Cycle  Time 

The  time  required  to  conceptualize,  design  and  produce  new  ship  designs  has  been  increasing  steadily  over 
the  years.  Consider  the  trends  for  naval  combatant  programs  shown  in  Figure  1 .  Conceptual  Design  time  (concept 
design  and  preliminary  design)  is  increasing  at  a  rate  of  1 .5  months  per  year    Contract  Award  time  (from  program 
start  through  completion  of  contract  design)  is  increasing  at  a  rate  of  3  months  per  year.  Time  to  deliver  completed 
ships  is  increasing  at  a  rate  of  5  months  per  year.  These  trends  are  coupled  with  exponentially  increasing  man-day 
efforts  required  to  deliver  ship  designs  (Figure  1).  These  trends  are  disturbing  as  they  represent  a  barrier  to 
providing  warfighters  with  timely  systems  necessary  to  meet  threats.  The  causes  of  these  trends  are  numerous  and 
will  be  discussed  in  depth  in  Chapter  2. 


1  RADM  Roger  B.  Home,  "Concept  to  Commissioning:  Ship  Design,  Acquisition  and  Construction  Process 
Improvement  Workshop  II",  Richmond,  VA,  May  6-7,  1991. 

2  Ryan  and  Jons,  "Improving  the  Ship  Design,  Acquisition  and  Construction  Process",  Association  of  Scientists  and 
Engineers,  28lh  Annual  Technical  Symposium,  April  11.  1991 

3  Tibbitts  and  Keane.  "Making  Design  Everybody's  Job".  Naval  Engineers  Journal.  May  1995,  page  286. 

4  Timothy  P  McCue,  "The  Dynamics  of  Naval  Shipbuilding-a  Systems  Approach ".  Department  of  Ocean 
Engineering  Thesis,  Massachusetts  Institute  of  Technology.  June  1997,  pages  23-44. 

6 


100000 


1  80000 


60000 


.S  40000 


s  20000 


s 


0 


1950      1960      1970      1980      1990 


160 

140 

fl20 

1 100 

e    80 


«    60 
O    40 


20 
0 


o  Delivery 
h  Award 
a  Design 


^^g^V 


1969   1974   1979   1984 


Figure  1  Combatant  Cycle  Time  Trends5 

The  reaction  to  the  D  AC  study  and  subsequent  ship  programs  since  the  realization  of  these  trends  was 
significant  reform  and  "modernization"  of  the  design  process.  These  reforms  include  revision  of  the  basic 
Department  of  Defense  (DoD)  acquisition  process  requirements  (Acquisition  Reform),  restructuring  of  the  design 
organization  to  be  inclusive  of  design  agents,  ship  constructors  and  customers  (IPPD/TPT  and  Concurrent 
Engineering),  and  application  of  data  processing  advances  (SBD  and  3-D  Product  Models). 

One  of  the  most  significant  process  improvements  has  come  in  the  form  of  acquisition  reform.  These  reforms 
have  been  realized  primarily  through  the  introduction  of  DoDINST  5000-2R.  the  basic  documentation  of  acquisition 
requirements 

Another  method  of  reducing  cycle  time,  reducing  cost  and  improving  performance  is  the  reform  of  design 
organizations.  Consider  the  past  approaches  to  naval  design. 6  In  the  1950s,  the  Navy  (namely  the  BuShips)  was 
responsible  for  complete  design  of  ships  and  in  many  cases,  the  construction  of  those  designs  at  naval  shipyards. 
This  approach  to  "in-house"  design  and  construction  was  appropriate  and  efficient  because  naval  ships  were 
relatively  simple  (designs  were  consistent  with  World  War  II  technologies).  Naval  designs  that  were  constructed  by 
private  shipyards  were  the  result  of  a  largely  "non-adversarial"  relationship  between  the  Na\y  and  industry . 

In  1960.  the  Secretary  of  Defense.  Robert  McNamara,  introduced  a  new  method  of  ship  acquisition:  Total 
Package  Procurement  (TPP).  This  transition  was  initiated  to  reduce  costs  and  introduce  system  design  of  ships 
based  on  "ilities"  (reliability,  maintainability,  survivability,  etc.)  Under  TPP.  the  Navy  independently  performed 
concept  formulation  (CF)  to  validate  operational  requirements  against  potential  ship  designs,  but  the  results  were 
withheld  from  industry.  Validated  requirements  (minus  design  suggestions)  were  "'thrown  over  the  wall"  to 
industry,  which  performed  independent  contract  definition  (CD).  CD  established  shipbuilder  designs  and  solutions 


?  Ryan  and  Jons,  "Improving  the  Ship  Design,  Acquisition  and  Construction  Process".  Association  of  Scientists  and 
Engineers,  28th  Annual  Technical  Symposium.  1 1  April  1991,  page  10-1 1. 

6  Keane  and  Tibbitts,  "A  Revolution  in  Warship  Design:  Navy-Industry  Integrated  Product  Teams",  Journal  of  Ship 
Production.  November  1996,  page  255-259. 
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that  optimized  utilization  of  their  construction  facilities.  However,  the  competitive  environment  prevented  the  Navy 
from  suggesting  specific  design  desires,  despite  the  fact  that  the  Navy  retained  responsibility  for  the  majority  of 
combat  systems  to  be  integrated  with  the  design.  As  a  result,  programs  such  as  the  LHA  and  DD-963  produced  high 
quality  ships  (the  result  of  industry  optimization  of  construction),  but  resulted  in  large  cost  overruns  (due  to  late 
design  changes  and  GFE/GFI/GFM  delays)  and  increasingly  adversarial  government-industry  relationships.8  As  a 
result,  TPP  fell  mto  disfavor. 

The  programs  of  the  1970's  saw  a  return  to  "in-house"  design  efforts  by  the  Navy.  However,  the  decline  of 
naval  shipyards  during  the  period  of  TPP  resulted  in  the  need  to  rely  entirely  on  private  shipyards  for  construction. 
The  newly  formed  Naval  Sea  Systems  Command  (NAVSEA)  was  responsible  for  all  phases  of  design  through 
contract  award.  The  only  involvement  of  shipbuilders  was  the  performance  of  producibility  studies  to  suggest 
largely  generic  improvements  to  the  design.  At  the  completion  of  contract  design,  the  design  specifications  were 
awarded  as  a  ship  design  support  contract  to  a  shipyard,  which  allowed  lead  ship  detailed  design  to  begin  even  while 
construction  contracts  were  being  negotiated  The  nature  of  the  design  process  at  this  point  allowed  the  Navy  to 
retain  significant,  centralized  control  of  the  design  throughout  the  life  the  acquisition.  However,  industry  was 
increasingly  constrained  by  their  late  participation  with  the  design,  resulting  in  higher  construction  costs. 

The  1980s  saw  an  attempt  to  bring  shipbuilders  into  the  process  sooner.  During  contract  design,  shipyards 
were  invited  to  participate  in  the  process  as  observers  and  to  introduce  extensive  producibility  enhancements  to  the 
design.  However,  the  potential  shipbuilders  could  not  achieve  consensus  on  the  design  approach  due  to  the 
substantial  differences  in  their  production  methods  and  facilities   As  such,  NAVSEA  designs  adopted  a  "lowest 
common  denominator"  approach.9  Simultaneously,  system  integration  issues  (such  as  introduction  of  the  Aegis 
Weapons  Systems  on  CG-47  and  DDG-5 1  class  ships)  became  a  dominant  cost  and  requirements  drivers  for  ship 
optimization  and  design.  The  result  was  the  introduction  of  collocation  of  design  agents  and  increased  use  of 
computer  aided  design  (CAD).  However,  these  efforts  fell  short  of  their  goals.  Centralized  design  control  by 
NAVSEA  meant  that  collocation  for  a  single  design  project  might  jeopardize  availability  of  design  resources  for 
other  design  projects.  As  for  CAD,  attempts  to  use  a  single  product  model  system  meant  translation  errors  and 
incompatibilities  among  as  many  as  six  different  CAD  systems  in  use  by  private  shipyards 

The  lessons  of  40  years  of  process  methods  are  being  applied  in  the  1990's  in  an  attempt  to  reverse  the  cycle 
time  trends.  With  downsizing  of  government  organizations.  NAVSEA  is  transitioning  from  centralized  design 
control  to  design  oversight.  Acquisition  reform,  centered  on  the  Federal  Acquisition  Streamlining  Act  (FASA).  the 
Federal  Acquisition  Reform  Act  (FARA).  and  DoD  Directive  5000. 1  (March  15.  1996)10,  provides  a  foundation 
from  which  government  and  industry  can  mutually  benefit  in  the  design  process.  Specifically,  these  reforms  are 


7  Keane  and  Tibbitts,  "Naval  Ship  Design  in  the  2 1st  Century",  Society  of  Naval  Architects  and  Marine  Engineers, 
September  14-19  1993,  page  19-3. 

Kenneth  Cooper,  Naval  Ship  Production:  A  Claim  Settled  and  a  Framework  Built.  Pugh-Roberts  Associates. 
Cambridge.  MA,  December  6.  1980. 

9  Keane  and  Tibbitts.  "A  Revolution  in  Warship  Design:  Navy-Industry*  Integrated  Product  Teams".  Journal  of  Ship 
Production,  November  1996,  page  257. 

10  Refer  to  Chapter  8.3.  Glossary  and  Abbreviations. 
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changing  the  timing  of  design  transition  from  government  to  industry.  Traditionally,  the  Navy  controlled  the  design 
through  contract  award;  at  which  time  CDRL's.  military  specifications,  and  GFE/GFM/GFI  were  transferred  to  the 
shipbuilder.  This  method  left  shipbuilders  little  room  for  producibility  and  design  improvements.  This  approach 
has  changed  under  acquisition  reform.  Now.  design  responsibility  is  transferred  to  industry  as  early  as  possible, 
following  or  even  during  concept  design.  Instead  of  very  specific  design  requirements,  current  requests  for  proposal 
(RFP's)  provide  industry  with  performance  specifications  and  concepts  of  operations  aimed  at  communicating  the 
nature  of  the  problem  to  be  solved  .  not  the  solution.  The  premise  of  reform  is  to  allow  industry  to  examine  the 
needs  of  government  and  react  to  those  needs  with  products  not  bounded  by  bureaucratic  constraints  or  government 
design  specifications.  The  goals  are  the  reduction  of  government  design  and  management  overhead  required  for 
centralized  design  control  and  to  provide  industry  with  the  incentive  to  seek  innovative  solutions  that  take  advantage 
of  technological  and  manufacturing  strengths. 

From  a  cycle  time  view,  acquisition  refonn  should  reduce  design  time  by  setting  specific  schedules  in  the 
RFP  for  competing  industries  (as  opposed  to  a  single  organization,  the  Navy,  producing  the  design.)  Thus,  failure  of 
one  entity  to  meet  the  timeline  will  result  in  their  loss  of  the  contract,  not  the  lengthening  of  the  process. 
Additionally,  the  transfer  of  the  design  earlier  in  the  process  will  result  in  less  total  information  being  transferred 
(thus,  less  chance  of  error)  and  open  lines  of  communication  at  a  time  when  concepts  and  requirements  are  much 
more  negotiable. 

To  facilitate  acquisition  reform,  a  number  of  specific  process  innovations  are  being  incorporated.  A  primary 
mechanism  is  the  introduction  of  Integrated  Product  and  Process  Development  (IPPD)/Integrated  Product  Teams 
(IPT) ' ' .    By  IPPD/TPT.  multi-disciplinary  teams  (representation  of  all  potential  elements  of  design  and  production 
with  customer  participation  is  mandatory)  examine  all  aspects  of  the  design  process  (requirements,  technology- 
alternatives,  cost.  ILS.  manning,  etc)  in  an  environment  that  promotes  communication.  The  methodology  builds  on 
the  notion  that  no  single  person  is  the  ultimate  expert.  Whether  actual  or  virtual,  collocation  is  critical  to  the 
process.  Integral  to  IPPD/IPT  is  concurrent  engineering12.  Concurrent  engineering  seeks  to  consider  all  life-cycle 
aspects  from  the  earliest  design  stages  through  manufacturing,  deployment,  operations  and  disposal.  These 
techniques  apply  some  basic  principles:  process  orientation,  team  approach,  empowerment,  and  open 
communications,  parallel  development  and  customer  satisfaction.  Cycle  time  should  be  shortened  as  critical  issues 
for  production  and  support  as  well  as  pro's  and  con's  of  design  options  are  resolved  early  in  the  process,  when 
rework  and  design  disruption  do  not  impact  the  process  as  greatly. 

In  addition  to  team  and  process  approaches,  the  design  cycle  is  being  improved  by  the  introduction  of 
improved  data  management  and  analysis.  The  use  of  3D  Product  Modeling13  seeks  to  integrate  3D  geometry, 
associativ  e  and  parametric  relationships  and  non-geometric  information  into  a  single  model  to  be  employed  from 
concept  design  through  ultimate  ship  disposal.  The  model  acts  as  the  repository  for  ship  design  and  production 


Simmons,  Assessment  of  Options  for  Enhancing  Surface  Ship  Acquisition.  Institute  for  Defense  Analyses.  March 
1996.  pg.  39-40. 

'  Baum  and  Ramakrishnan.  "'Applying  3D  Product  modeling  Technology  to  Shipbuilding ".  Marine  Technology, 
January  1997,  pg.  56. 


information,  and  integration  of  logistics  and  life-cycle  data.  The  model  facilitates  inputs  and  outputs  for  all  design 
analysis  including  cost  and  mission  effectiveness,  engineering  assessment  and  producibility .  An  example  of  a 
generic  product  model  is  shown  in  Figure  2.  The  model  enables  virtual  environment  design  reviews,  virtual 
shipyards,  and  simulation-based  design.  Non-geometric  data  is  placed  in  a  relational  database  system.  3D  solids 
and  surfaces  are  defined  once  with  geometry  modeling  and  paramedics  and  linked  to  multiple  locations  with  an 
associativity  feature.  The  design  is  stored  in  a  heterogeneous  distributed  database  managed  by  a  relational  database 
product  data  manager  (PDM).  Users  establish  design  rules  (analysis  tools,  design  parameters,  constraints)  from 
which  the  design  is  automatically  generated. . .  when  rule  violations  occur,  the  user  is  notified  and  prompted  to 
resolve  conflicts.  Ultimately,  a  series  of  3D  Product  Models  for  various  ship  designs  could  form  a  "Knowledge 
Base"  from  which  future  designs  could  be  rapidly  developed. 


Geometry  Models 


Attribute  Models 


Behavior  Models 


Common  Models 


Figure  2  Generic  3D  Product  Model 

A  key  feature  of  a  3D  product  model  is  the  capability  to  facilitate  Simulation-Based  Design  (SBD)14.  SBD 
allows  designers  to  assess  technology  insertion  and  design  concepts  in  the  virtual  environment  using  Virtual  Reality 
(VR).  very  large  complex  database  systems,  optimization  techniques,  complex  data  visualization.  Artificial 
Intelligence  (AI)  and  high  performance  networking.  SBD  realizes  cost  savings  and  performance  enhancements 
through  Modeling  and  Simulation  (M&S)  of  design  options  (vice  physical  prototype  construction)  followed  by 
direct  extraction  of  production  instructions  (CAD/CAM/CAE15)  from  virtually  tested  designs.  When  fully  realized. 
3D  modelmg  and  SBD  will  allow  dynamic  model  interactions  of  design  parameters  among  the  major  design 
participants  (Program  Manager.  Mission  Analyst.  Naval  Architect,  Mechanical  Specialist,  Purchasing  Agent. 
Arrangement  Specialist.  Structural  Specialist.  Production  Specialist,  Operational  Personnel.  Manufacturing 
Specialist),  and  utilize  these  relationships  to  perform  all  required  concept  analysis  (Mission  Analysis.  Mechanical 
System  Analysis,  Ship  Arrangement  Scenario.  Operational  Simulation.  Coupled  Hydrodynamic/Structural  Analysis. 


13  Ibid.,  pg.  56-65. 

14  Polmi,  Wooley,  Butler,  "Impact  of  Simulation-Based  Design  on  Today's  Shipbuilders",  Marine  Technology. 
January  1997.  pg.  1-9. 

15  Tibbitts  and  Keane.  "Making  Design  Everybody's  Job ",  Naval  Engineers  Journal,  May  1995,  page  283 
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Manufacturing  Simulation,  and  Cost  Analysis)  in  a  virtual  environment.  The  impact  on  design  cycle  time  should  be 
the  ability  to  rapidly  test  design  concepts  and  resolve  design  concerns  prior  to  expenditure  of  time  and  resources  on 
physical  prototypes. 

These  reforms,  though  certainly  more  refined,  are  not  entirely  without  precedence.  Early  design  hand-off  was 
first  used  during  TPP.  IPPD  methodology  was  implemented  during  the  1970's  for  the  FFG-7  program.  Collocation 
and  CAD  technology  was  implemented  during  the  DDG-5 1  and  CG-47  programs.  Total  system  trade-offs  of  cost 
and  performance  have  been  in  use  to  varying  degrees  for  several  decades.  Thus,  the  issue  is  now  one  of  how  much 
of  each  reform  to  implement,  how  will  implementation  impact  ultimate  performance  and  cost,  and  will  external 
forces  negate  the  gains  brought  about  by  reforms'7 

These  questions  are  especially  important  in  light  of  the  long  duration  of  design  programs.  For  instance, 
typical  durations  for  combatant  ships  can  exceed  12  years;  typical  weapons  system  programs  require  15  years  for  the 
1st  production  item,  and  official  DoD  timelines  (satisfying  all  program  requirements)  can  exceed  22  years.16  Those 
programs  that  have  undergone  the  reforms  of  the  last  10  years  have  yet  to  produce  quantitative  results  satisfactory 
for  analysis  of  improvement  effectiveness:  "There  are  good,  although  anecdotal,  examples  of  this  foundation 
actually  being  propagated  in  the  field  for  our  major  programs.1  "  Is  there  a  way  to  test  and  optimize  improvements 
prior  to  implementation'7 

Consider  the  traditional  project  management  methods  listed  in  Table  1 .  These  methods  focus  primarily  on 
operational  issues  necessary  to  define  project  work  structure,  resource  availability  and  requirements,  and  budget 
requirements  and  allocations.  The  methods  are  becoming  increasingly  mature  with  development  of  software  suites 
like  Microsoft  Project®.  At-Risk®  and  DoD  ICOM  (Input.  Constraint,  Output  and  Mechanism)  packages.  The 
approaches  assume  a  well  ordered  project  that  progresses  in  well-defined  stages  to  completion.  In  particular,  the 
techniques  assume  a  linear,  or,  in  the  case  of  PERT/ICOM.  limited  feedback  process.  Process  improvements  can  be 
intimated  and  assessed  by  examining  the  risk-benefit  of  options  or  by  in  depth  analysis  of  Critical  Paths  in  the 
process.  However,  this  analysis  often  fails  to  detect  systemic  impacts  of  a  given  process  improvement  or  realize 
strategic  goals  for  improvement  processes.18  At  issue  is  the  inability  of  these  methods  to  capture  decision  process 
logic,  political/social  factors,  workplace  environment  and  other  human  factors.  Additionally .  their  static  nature 
cannot  capture  dynamics  like  schedule  pressure,  workforce  experience  shifts  or  rework  issues.  System  dynamics 
can  provide  a  methodology  to  capture  these  issues  and  provide  the  strategic  analysis  necessary  to  optimize  process 
improvements. 


16  Ryan  and  Jons,  "Improving  the  Ship  Design.  Acquisition  and  Construction  Process",  Association  of  Scientists  and 
Engineers.  28th  Annual  Technical  Symposium.  1 1  April  1991.  page  11. 

1   Dr.  Paul  Kaminski.  Under  Secretary  of  Defense  (Acquisition  and  Technology),  interview  in  Program  Manager, 
January-February  1997,  page  12. 

18  Rodrigues  and  Bowers.  "System  Dynamics  in  project  management:  a  comparative  analysis  with  traditional 
methods".  Svstem  Dynamics  Review,  Volume  12  number  2.  Summer  1996.  page  124. 

11 


Technique/Tool 

Purpose 

Work  Breakdown  Structure  (WBS) 

Basic  definition  of  the  project  work.  Precedes  the 
project  schedule  and  cost  estimates 

Gantt  Charts 

Representation  of  project  schedule,  may  show 
simple  precedence  relationships 

Project  Network  Techniques:  PERT.  CPM.  PDM. 
GERT 

Analysis  of  scheduling  impacts  based  on  precedence 
relationships,  cost  estimatioa  resource  allocation, 
management  and  risk  analysis,  and  input -output 
relationships 

Dynamic  Strategic  Planning  (DSP) 

Cost  benefit  analysis  incorporating  risk 
relationships  of  net  present  value  (NPV)  for  options 
against  the  customer  utility  for  those  options 

Table  1  Traditional  Project  Management  Techiques1920 

System  dynamics  has  been  successfully  applied  to  strategic  project  management  for  many  decades.  Since 
1964.  dynamic  models  have  been  applied  to  projects  ranging  from  naval  construction  (1980  Litton-Ingalls 
Shipbuilding  Litigation  model)  to  large-scale  DoD  software  development  projects.21  These  models  have  accurately 
identified  key  causes  of  process  degradation  includmg  interdependencies  created  by  process  concurrence,  impacts  of 
project  scope  change,  and  relationship  of  schedule  pressure  to  productivity. 

Recently,  several  dynamic  models  have  been  created  to  address  the  issue  of  strategic  process  improvement  in 
private  shipyards.  The  McCue  Production  Model  (MIT  1997::)  demonstrated  the  impact  of  manpower  fluctuations 
on  productivity  and  cost  for  Bath  Iron  Works  and  Ingalls  Shipyard.  The  focus  of  the  McCue  model  on  manpower 
loading  provides  tremendous  insight  into  the  necessity  to  maintain  workforce  levels,  even  in  light  of  short-term 
economic  loss,  in  order  to  maintain  the  agility  necessary  to  compete  for  emergent  contracts.  The  Simulation  of  New 
Acquisition  Processes  (SNAP)  program  (DDI  1997:3)  bridges  the  gap  between  system  dynamics  models  and 
operational  methods  by  demonstrating  the  dynamic  flow  of  shipyard  work  against  changing  resource  availability, 
personnel  productiv  ity  and  schedule  pressure.  The  model  is  especially  useful  because  it  incorporates  ship  work 
breakdown  structures  familiar  to  shipyard  managers.  ..thus,  instilling  a  high  level  of  confidence  in  the  results  of 
process  analysis.  Models  are  also  being  applied  to  other  naval  process  issues  such  as  operations  and  support  costs. 


'9  Ibid,  page  121. 

"°  Richard  de  Neufville.  Applied  Systems  Analysis:  Engineering  Planning  and  Technology  Management,  McGraw- 
Hill  Inc.  1990. 

_1  Rodrigues  and  Bovvers,  "System  Dynamics  in  project  management:  a  comparative  analysis  with  traditional 
methods".  System  Dynamics  Review,  Volume  12  number  2.  Summer  1996,  page  128. 

'  Timothy  McCue.  "The  Dynamics  of  Naval  Shipbuildmg-a  Systems  Approach".  Thesis  for  Massachusetts  Institute 
of  Technology,  June  1997. 

23  Alfeld,  Wilkms  and  Pilliod.  "The  Virtual  Shipyard:  A  Simulation  Model  of  the  Shipbuilding  Process",  The 
Society  of  Naval  Architects  and  Marine  Engineers.  April  21-23.  1997. 
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naval  forces  requirements  and  cost  optimization24,  and  the  interaction  of  DoD  acquisition  programs25.  The  effect  of 
this  effort  is  the  increased  application  of  system  dynamics  as  a  tool  to  assess  and  optimize  process  improvements 
from  the  strategic  level.  However,  there  has  not  yet  been  a  significant  move  to  apply  simulation  models  to  the 
design  process. 

A.  Unacceptable  cycle  time  trends  have  lead  design  managers  to  implement  many  process 
improvements  aimed  at  reversing  these  trends.  However,  insufficient  time  has  passed  to  determine  the 
full  effectiveness  of  these  improvements. 

B.  Given  the  duration  of  the  design  process  and  the  lack  of  fidelity  in  traditional  project  management 
methods  to  strategically  analyze  effectiveness,  system  dynamics  should  be  applied  to  naval  design  to 
provide  a  means  of: 

1.  Analyzing  the  causes  of  cycle  time  groivth 

2.  "Gaming  "  potential  process  changes  to  determine  effectiveness  and  relative  risks. 


^A.2      Requirements  and  Design  Performance 

Like  the  problem  of  cycle  time  trends,  performance  issues  are  an  increasing  concern  to  warfighters  and 
designers  alike.  Requirements  assessment  is  seeing  significant  introduction  of  new  techniques  to  assess  risk  and 
effectiveness  long  before  the  laying  of  steel  or  the  programming  of  weapons  software. 

"The  modern  warship  (is  the)  most  complex  machine  devised  by  man.*'26  Their  complexity  crosses  every 
discipline  of  modern  engineering  and  physics  from  fluid  dynamics  to  computer  network  design  to  nuclear 
engineering.  The  complexity  is  further  increased  by  the  dynamic  interactions  of  these  unique  disciplines  resulting  m 
the  integration  of  a  single  system.  The  ad  hoc  optimization  process,  which  creates  this  system,  is  based  on 
compromise  and  trade-off  of  various  requirements  and  system  options.  However,  with  ever  growing  design 
complexity  comes  an  increasingly  unanswerable  question:  has  the  optimal  solution  been  achieved'  Resoundingly, 
the  answer  is  no.  and  the  difficulty  is  translating  operationally  required  mission  effectiveness  into  optimized  design 
parameters. 

Until  recently,  mission  effectiveness  was  defined  qualitatively.  Performance  requirements  were  provided  to 
designers,  but  the  operators  had  few  means  to  quantitatively  assess  the  effectiveness  of  such  requirements,  and 
designers  were  provided  little  room  or  guidance  to  trade  requirements  and  cost.  For  example,  requirements  would 


24  Towles.  Rocholl.  Jeffers  and  Piatt,  "Force  Affordability  Modeling:  the  Dynamic  Investment  Balance  Simulation 

(DIBS)",  presentation  to  Naval  Surface  Warfare  Center  Carderock  Division.  Bethesda.  MD.  April  15,  1997. 

"5  Towles.  Rocholl.  Jones,  Jeffers  and  Piatt.  "System  Wormhole  Analysis  Tool  (SWAT):  a  Simulation  Based 

Acquisition  Initiative."  presentation  to  Naval  Surface  Warfare  Center  Carderock  Division.  Bethesda.  MD,  October 

27,  1997. 

26  Gale  and  Scott.  "Earlv  Stage  Ship  Design  Seminar",  Societv  of  Naval  Architects  and  Marine  Engineers,  October 

1995. 
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state  'cam'  out  anti-submarine  operations  in  the  North  Atlantic"  or  "maintain  X  knots  in  sea  state  5."     Such 
statements  are  misleading  to  both  requirements  setters  and  designers.  The  first,  more  general  statement,  does  not 
indicate  any  level  of  trade-off  or  even  a  notion  of  what  "'anti-submarine  operations"  might  entail.  The  designer  is 
forced  to  assume  an  engineering  definition  and  may  inevitably  misinterpret  the  operators"  true  intentions.  The 
second  more  specific  requirement  removes  all  potential  for  trade-off  against  other  variables,  and  does  not  allow 
alternate  solutions  to  the  problem.  Under  these  circumstances,  designers  are  often  detached  from  customers 
(operators),  and  are  forced  to  make  critical  decisions  without  explicit  feedback  until  the  system  is  operational. 

For  the  designers,  there  is  a  lack  of  clarity  as  to  who  the  customer  is:28  the  operator,  the  ship  builder  or  just 
the  next  designer  in  the  design  chain.  There  is  a  tendency  to  under-fund  R&D  efforts  and  requirements  setting 
processes  which  would  allow  both  designers  and  operators  to  reach  better  optimized  solutions.  These  factors 
combine  to  add  confusion  and  delays  to  the  requirements  setting  process. 

Requirements  setters  within  the  operating  forces  of  the  Navy  (OPNAV).  are  frequently  focused  on  details  and 
fail  to  communicate  'big  picture"  needs.  Turnover  is  also  rapid  and  OPNAV  personnel  may  be  transferred  before 
they  understand  and  appreciate  the  problem.29  Additionally,  the  customer  lacks  understanding  of  the  ship  design 
process.  Specifically,  the  fleet  operators  aren't  able  to  understand  how  specific  requests  for  performance  translate 
into  design  trade-offs.30 

When  performance  changes  are  requested  (due  primarily  to  out-of  phase  development  programs  and 
conflicting  requirements  at  various  stages  of  design  definition31),  the  resulting  disruption  to  the  design  process  is 
significant.  For  instance.  Table  2  shows  how  design  priorities  changed  over  the  course  of  the  DDG-51  preliminary 
design  effort.  Customer  priority  changes,  particularly  with  respect  to  energy  conservation,  resulted  in  a  large  design 
effort  (culminating  in  several  design  variants  and  two  independent  design  studies32)  to  analyze  designs  which 
incorporated  the  RACER  (Rankine  Cycle  Energy  Recovery)  propulsion  system.  However,  total  ship  system  impacts 
of  RACER  and  program  risks  related  to  the  RACER  R&D  schedule  (not  in  phase  with  DDG-5 1)  ultimately  resulted 
in  cancellation  of  the  RACER  integration  with  DDG-51  and  a  further  realignment  of  performance  priorities  (highest 
to  lowest)  in  the  DDG-51  contract  phase  to33: 

a.  Combat  system  capability 

b.  Speed  and  endurance 

c.  Survivability 
d     Habitability 


2  David  Brown.  "Naval  Architecture".  Naval  Engineers  Journal.  Januarv  1993,  page  43. 

28  Ibid,  page  2-22. 

"  Roger  Home.  Improving  the  Ship  Design,  Acquisition  and  Construction  Process:  Strategic  Plan,  Naval  Sea 

Systems  Command  Washington  DC,  June  1991,  page  2-20. 

30'  Ibid,  page  2-21. 

3' Ibid  page  2-21. 

32  Andy  Sum.aers, .  DDG  5 1  Guided  Missile  Destroyer  Preliminary  Design  History.  Naval  Sea  Systems  Command 
June  1984,  page  B-l. 

33  Andy  Summers,  DDG  5 1  Guided  Missile  Destroyer  Contract  Design  History ,  Naval  Sea  Systems  Command  June 
1987.  page  3-1. 
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e.     Design  flexibility  and  growth  potential 
These  changes  lead  to  further  delays  and  generated  additional  iterations  of  the  DDG-5 1  design.34  Changing 
priorities,  unclear  requirements  relative  to  total  system  impacts  and  out  of  phase  development  programs  generate 
design  effort. 


Attribute 

Priority  at  Start 

Priority  at  Finish 

Combat  Capability 

High 

High 

Acquisition  Cost 

High 

Medium  High 

Operability 

Medium  High 

Medium 

Passive  Survivability 

Medium  High 

High 

Energy  Conservation 

Medium  High 

High 

Future  Growth  Flexibility 

Medium  High 

Low 

Active  Survivability 

Medium 

Medium  High 

Ship  Displacement 

Medium 

High 

Manning  Reductions 

Medium 

Low 

Habitability 

Low 

Medium  High 

Minimum  Risk 

Low 

Low 

Standardization 

Low 

Low 

Table  2  Preliminary  Design  Priorities  at  Beginning  and  End  of  Design  Phase35 

As  a  result  of  the  noted  shortcomings  (dating  back  to  the  late  1980's).  the  DAC  study36  and  other  process 
improvement  efforts  such  as  Secretary'  of  the  Navy  Instruction  5000.2B3  .  the  requirements  process  now  institutes 
improved  performance  assessment  mechanisms.  These  mechanisms  provide  for  structured  input  of  requirements, 
assessment  of  engineering  solutions  with  respect  to  those  requirements  and  feedback  from  operators  regarding 
system  solution  options.  Some  of  these  improved  methods  include  Quality  Function  Deployment  (QFD).  Analytical 
Hierarchy  Process  (AHP).  and  Genetic  Algorithms.38 

The  QFD  method,  which  was  devised  by  a  shipyard  in  Kobe,  Japan  to  address  the  same  problems  relative  to 
its  customers,  provides  a  structured  process  of  taking  customer  needs  (stated  in  the  subjective,  qualitative  and  non- 
technical "voice  of  the  customer")  and  translating  those  needs  into  "corporate  language"'  (quantitative  and  technical 


34  Verne  Stortz.  "DDG-5 1  Cost  Estimate  Log",  Naval  Surface  Warfare  Center  Carderock  Division.  Bethesda.  MD. 
October  1984 

3?  Andy  Summers. .  DDG  5 1  Guided  Missile  Destroyer  Preliminary  Design  History.  Naval  Sea  Systems  Command 
June  1984.  page  3-1  and  3-3. 
36  Ibid,  page  2-16. 

3  John  Dalton,  Implementation  of  Mandatory  Procedures  for  Major  and  Non-Major  Defense  Acquisition  Programs 
and  Major  and  Non-Major  Information  Technology  Acquisition  Programs  (SECNAVINST  5000. 2B).  Department  of 
the  Navy,  Washington  DC.  December  6.  1996.  Appendix  II. 

38  Defense  Acquisition  Deskbook  Joint  Program  Office,  "Defense  Acquisition  Deskbook  Version  2.3.101",  Wright- 
Patterson  Air  Force  Base.  Ohio,  March  31,  1998. 
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parameters  required  by  designers.  )39  The  customer  traits  are  commonly  referred  to  as  Measures  of  Effectiveness 
(MOEs)  while  design  performance  attributes  are  Measures  of  Performance  (MOPs).  QFD  provides  a  qualitative 
mapping  from  MOEs  to  MOPs.  The  two  "languages"  are  translated  via  a  matrix  referred  to  as  the  "House  of 
Quality"  (see  Figure  3  below.)  The  mapping  highlights  synergies  and  conflicts  between  design  options  and 
competing  customer  requirements.  As  a  result,  customers  and  designers  can  visualize  design  trade-offs  and  propose 
alternative  solutions.  The  process  is  iterative  and  its  greatest  use  is  as  a  means  to  facilitate  communication  between 
customers  and  engineers  throughout  the  design  process.  The  method  has  proven  useful  in  Navy  programs  ranging 
from  the  Joint  Advanced  Strike  technology  (J AST)  program  to  the  Next  Generation  Carrier  Program  (CVX.)40 
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40 


Tibbitts  and  Keane,  "Making  Design  Everybody's  Job",  Naval  Engineers  Journal.  Mav  1995.  page  287. 
Ibid,  page  287. 

International  TechneGroup  Incorporated  (ITI).  http://www.iti-oh.com/cppd/qfd/qsoft.htm. 
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Whereas  QFD  is  a  qualitative  method  of  communicating  performance  attributes.  AHP  aims  to  quantify 
performance  attributes  in  a  manner  which  allows  designers  to  search  a  boarder  solution  space  while  still  meeting 
fundamental  performance  needs.  Specifically,  requirement  setters  and  engineers  establish  a  well  defined  mutually 
agreed  to  set  of  performance  attributes  and  the  quantifiable  values  of  those  attributes.  The  requirement  setters  then 
weight  the  attributes  through  a  series  of  pair-wise  comparisons.  The  result  of  such  comparison  is  a  vector  of 
weighting  factors  relating  the  "goodness"  of  each  attribute  against  another.  Thus,  engineers  can  explore  the  entire 
solution  space  and  determine  the  optimization  of  customer  needs  within  that  space.  An  example  of  this  method  of 
has  been  to  quantify  variables  ranging  from  producibility  of  ships  to  life-cycle  cost  to  combat  performance.42  In  this 
example,  subject-matter  experts  were  questioned  regarding  a  number  of  performance  attributes.  Those  attributes  as 
well  as  the  weighting  factors  for  a  number  of  ship  types  (Destroyers  and  Carriers)  are  shown  in  Table  3  below . 
Using  the  AHP  method,  a  designer  would 

a.  measure  the  attribute  values  (MOPs)  for  generated  system  designs  (such  as  sustained  speed  is  20. 1 
knots  or  25.6  knots). 

b.  normalize  the  MOPs  against  previously  agreed  goal  and  threshold  values  (such  as  20. 1  is  0.014  and  25.6 
is  0.80  to  a  goal  of  27  knots  and  a  threshold  of  20  knots)  or  ask  customers  to  re-evaluate  design 
attributes  directly  by  additional  pair-wise  comparison  (to  generate  a  summary  values  from  0  to  1  for  a 
parameter  like  modularity). 

c.  multiply  normalized  MOPs  times  the  weightings  for  each  parameter  which  in  turn  generates  top-level 
MOEs  for  each  attribute  category  (such  as  0.8  times  0.3 174  is  0.2539  for  speed  and  the  total  of  all  MOPs 
for  Operational  Capability  adding  to  a  value  such  as  0. 1 12). 

d.  then  sum  the  MOEs  to  determine  an  Overall  Measure  of  Effectiveness  (OMOE)  value  for  each  design 
(such  as  design  1  is  0.23  and  design  2  is  0.45). .  the  highest  OMOE  design  is  the  optimal  customer 
directed  design  relative  to  the  other  scored  designs. 


,:  Wilkins.  Kraine  and  Thompson.  "Evaluating  the  Producibility  of  Ship  Design  Alternatives".  Journal  of  Ship 
Production,  August  1993.  page  196-201. 
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Ship  Performance  Criteria 

DD 

CVN 

Operational  Capability 

0.5971 

.07009 

Payload  Carrying  Capacity 

0.1293 

0.0666 

Payload  Effectiveness 

0.3030 

0.3252 

Mobility 

0.1194 

0.0362 

Speed 

0.3174 

0.4444 

Endurance 

0.5110 

0.4444 

Maneuverability 

0.1716 

0.1111 

Availability 

0.2516 

0.1814 

Survivability 

0.1967 

0.3907 

Operational  Efficiency 

0.2106 

0.2020 

Manning 

0.3768 

0.7142 

Habitability 

0.2066 

0.1429 

Safety 

0.4166 

0.1429 

Future  Growth  Margin 

0.1924 

0.0971 

Weight  Margin 

0.2460 

0.3214 

KG  Margin 

0.1582 

0.3214 

Volume  Margin  (density) 

0.2060 

0.3214 

Modularity 

0.3898 

0.0357 

43 


Table  3  Ship  Performance  Weighed  by  Analytical  Hierarchy  Process  Methodology" 

The  previous  methods  provide  both  a  means  to  define  customer  needs  relative  to  designer  attributes  and 
trade-off  specific  designs  against  each  other  in  a  structured  environment.  Genetic  algorithms  pnnide  the  final  step 
in  system  performance  optimization  by  systematically  enabling  designers  to  search  a  highly  non-lmear  design  space 
for  the  overall  optimal  solution  relative  to  the  user  defined  OMOE.  Specifically,  genetic  algorithms  take  a  series  of 
design  parameters  or  "genetic  materials"  (such  as  LBP.  a  series  of  discrete  combat  systems  suites  or  various  hull 
material  mixes),  generate  designs  from  those  genes,  assess  the  OMOEs  for  the  resulting  designs,  "mate"  the  designs 
with  each  other  to  generate  new7  "generations"  of  designs,  introduces  "mutations"  to  a  limited  number  of  the  genes  in 
each  generation,  and  continues  the  process  until  the  design  no  longer  improves  or  "evolves."  Traditional  AoA 
methodology  derives  optimization  of  the  design  space  through  directed  exploration  of  an  overly  large  number  of 
design  alternatives.  Such  exploration  is  only  possible  using  design  synthesis  tools  like  the  Advanced  Surface  Ship 
Evaluation  Tool  (ASSET).  Such  tools  allow  a  small  team  of  designers  to  rapidly  develop  and  balance  a  large 
number  of  ship  alternatives.  For  example,  the  current  CVX  program  is  exploring  design  in  three  stages  (airw  ing  size 
and  composition  alternatives,  propulsion  alternatives  and  system  alternatives)  with  as  many  as  30  designs  per  stage. 


43 


Ibid,  page  200. 
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Past  explorations  using  design  synthesis  programs  like  DD08  and  ASSET  have  generated  as  many  as  1000  different 
ship  designs  in  an  effort  to  ensure  an  optimum  solution.44  However,  even  with  synthesis  tools,  much  the  design 
work  is  still  manual,  such  as  topside  arrangement  of  a  combat  system  suite  or  flight  deck  design  in  a  CAD 
environment.  As  such,  designers  still  must  approach  the  analysis  of  the  solution  space  as  an  'experimental  design*', 
which  is  linear.  Given  the  increasing  complexity  of  current  designs  and  the  time  required  to  generate  a  single 
design,  it  is  necessary  to  have  a  method  like  genetic  algorithms  to  ensure  not  only  local,  but  global  optimization  of 
the  solution.  As  the  design  space  is  highly  non-linear,  sub-optimized  solutions  are  often  pursued  (see  Figure  4.) 
Genetic  algorithms  can  avoid  such  occurrences  by  not  focusing  the  search  m  a  linear  manner  (as  with  by  a  staged 
AoA  approach)  but  evolving  beyond  local  optima  to  achieve  the  peak  solution.  The  use  of  such  approaches  are 
proving  successful  both  in  academic  pursuits  of  design  (Mark  Thomas  and  Allan  Andrew  theses)  and  active 
programs  (Joint  Strike  Fighter  Program  use  of  SNAP45). 

Performance  and  the  systematic  optimization  of  performance  is  a  key  concern  to  operators  and  designers 
alike.  However,  the  customer  oriented  methods  of  QFD  and  AHP,  along  with  the  optimization  techniques  of  AHP 
and  Genetic  Algorithms,  provide  means  to  overcome  past  concerns.  The  Navy  is  beginning  to  apply  these 
techniques  with  success. .  .but  the  question  remains  whether  these  successes  are  enhancements  to  design  performance 
alone,  or  whether  the  dynamic  impacts  of  performance  enhancements  will  result  in  cost  and  cycle  time  growth. 
These  impacts  will  be  addressed  further  in  Chapter  2. 


44  Myron  Ricketts.  Manual  for  Naval  Surface  Ship  Design  Technical  Practices.  Naval  Sea  Systems  Command, 
Washington  DC,  1980.  Volume  1.  page  5-35. 

45  Alfeld  and  Shepard,  "SNAP-Simulating  New  Acquisition  Processes".  CA1V  Workshop.  Decision  Dynamics  iNC. 
11-12  July  1997. 

19 


Evolutionary  Strategies 
will  find  the  best  solution 
within  the  solution  space 


Multiple  Local  Optima 

Large  Flat  Areas 

Non-optimal  solutions 

Even  when  the 
landscape  changes 


Figure  4  Optimization  and  Genetic  Algorithms46 


1.1.3      Cost 


In  addition  to  the  need  to  achieve  required  performance  within  a  constrained  schedule,  modern  warships  must 
also  be  cost  effective.  The  cost  of  ships  has  been  steadily  increasing,  well  above  obvious  increases  due  to  inflation. 
The  DAC  study  shows  an  alarming  growth  trend.  Average  combatant  ship  acquisition  cost  in  equivalent  dollars 
(normalized  in  the  study  to  FY90)  has  increased  linearly  over  800%  per  vessel  over  a  thirty  year  period.4    This  trend 
alone,  has  represented  the  single  most  critical  factor  driving  the  need  for  acquisition  reform.  As  such,  strategic  cost 
analysis  and  cost  analysis  tools  have  received  significant  emphasis  in  the  last  decade. 

There  are  a  multitude  of  reasons  for  this  trend.  Consider  the  list  of  cost  roadblocks  disclosed  during  the  DAC 
Study  (Table  4).  Many  of  the  listed  concerns  (construction  delays  from  late  design  changes  and  GFE/GFI.  lack  of 
shipbuilder  producibility  inputs,  and  failure  to  fully  explore  design  options  prior  to  preliminary  and  contract  design) 
have  already  been  noted  as  equal  problems  related  to  schedule  and  performance. 


46 


Ibid. 


Ryan  and  Jons.  "Improving  the  Ship  Design.  Acquisition  and  Construction  Process".  Association  of  Scientists  and 
Engineers,  28th  Annual  Technical  Svmposium.  1 1  April  1991,  page  11. 
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Too  many  changes  after  contract  award 

Requirements  setting  without  rigorous  cost-benefit  analysis 

Lack  of  cost  awareness  or  cost  analysis  capability  organic  to  the  design  community 

Inefficient  shipbuilding  practices 

Awards  based  on  unrealistic,  low  bids 

Late  delivery  of  GFI/GFE 

Labor  intensive  ship  designs 

Insufficient  production  and  future  growth  margins 

Lack  of  system  architecture  to  accept  change 

Out  dated  specifications,  practices  and  margins 

Under-funding  of  Concept  Design  Phases 

Increasing  complexity  and  cost  of  combat  systems 

Excessive  costs  associated  with  programmatic  documentation 


Table  4  DAC  Study  Cost  Roadblocks48 

The  most  noteworthy  cause  of  cost  growth  in  naval  design  is  the  failure  to  leverage  the  relationship  between 
cost  and  time.  Consider  Figure  5.  In  the  early  stages  of  design,  decisions  are  made  that  define  the  general 
characteristics  of  the  ship.  Those  initial  decisions  have  not  traditionally  incurred  large  costs  (i.e.  concept  design 
funding  has  been  limited),  but  they  do  produce  future  costs  by  the  definition  of  specific  ship  design  choices.  For 
example,  the  result  of  concept  design  may  indicate  the  desired  vessel  to  be  a  destroyer,  approximately  465  ft  long. 
6800  Iton  light  ship  displacement,  capable  of  30  kts  sustained  speed  using  4  LM-2500  engines,  with  350  personnel. 
1  5754  DP  Gun.  96  VLS  cells  and  the  Aegis  weapon  system  centered  around  the  SPY- ID  radar  system.  The 
description  does  not  provide  enough  detail  to  construct  a  ship,  but  it  is  good  enough  to  estimate  acquisition  cost  to 
within  80%  probability  of  accuracy    The  reason  is  that  historically,  the  above  factors  will  result  in  80%  of  the  total 
cost  of  the  ship    As  the  design  process  matures,  greater  design  detail  is  expressed,  incurring  greater  costs  through 
increased  design  effort  and,  ultimately,  construction.  However,  this  detail  does  not  create  substantial  changes  in  end 
cost.    For  our  example,  later  design  stages  may  change  the  length  to  466  ft.  the  deckhouse  may  be  constructed  from 
steel  vice  aluminum,  and  the  scantlings  in  the  double  bottom  may  be  increased  for  increased  defense  from 
underwater  explosions.  However,  these  changes  will  not  result  m  significant  cost  changes  beyond  the  initial 
estimate.  This  fact  will  be  increasingly  important  with  respect  to  combat  system  impacts  on  cost  (discussed  below). 
Thus,  the  levels  of  cost  "lock-in"  and  cost  incurred  are  inversely  proportional. 


48 


Ibid.,  page  14 
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MSO       MSI 
Concept  Design 


MS2 


Detailed  Design 


Na\y  Responsibility 


Industry  Responsibility 


Many  Participants 
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One 


R&D  Dollars 


SCN  Dollars 


Figure  5  Key  Transitions  in  the  Design  Process 

This  relationship  can  be  further  demonstrated  in  the  methods  of  managing  weight  and  weight  based  costs 
during  the  design  process.  Consider  a  typical  trend  for  weight  and  KG  demonstrated  in  Figure  6.  Despite  short-term 
fluctuations,  the  overall  trend  (indicated  by  the  included  trend  line)  is  that  of  exponentially  decaying  growth  towards 
a  final  value,  namely,  the  light  ship  weight  at  launch.  It  is  necessary  that  convergent  behavior  in  all  aspects  of  the 
naval  design  exist.  Otherwise,  it  would  be  impossible  to  determine  whether  the  completed  ship  would  function 
desirably  as  a  system  (i.e.  float  and  float  upright.)  It  is  likewise  expected  that  the  values  for  properties  such  as 
weight.  KG.  electrical  load  etc.  at  the  beginning  of  contract  design  will  be  exceeded  during  detailed  design;  and 
even  further  exceeded  during  the  expected  life  of  the  ship.  As  the  design  matures,  assumptions  regarding  system 
weights,  locations,  scale,  etc,  are  refined.  To  err  conservatively,  the  assumptions  are  adjusted  with  margins  to  reflect 
potential  growth.  Margins  arc  added  to  those  system  values  (weight.  KG.  powering,  etc.)  that  are  critical  to  ship 
performance.  Table  5  shows  weight  and  KG  margins  used  for  the  design  naval  surface  combatants.  These  margins 
are  considered  the  minimum  additional  weight  or  moment-arm  that  should  be  included  in  a  design  to  account  for 
uncertainty  in  assumptions.  At  the  conclusion  of  a  design  phase,  the  design  managers  may  choose  to  reduce  or 
eliminate  margins  from  previous  stages  as  the  level  of  confidence  in  the  current  design  values  (reflective  of  the  level 
of  detail  achieved)  is  increased.  This  trend  is  displayed  for  the  DDG-5 1  program  in  Figure  7. 
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Figure  6  DDG-51  Contract  -  Detailed  Design  Weight  and  KG  Trends4 
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Mike  Jeffers,  Interview  at  Naval  Surface  Warfare  Center  Carderock  Division.  Bcthesda,  MD,  November  12.  1997. 
Ibid. 
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Weight  Margin 

Mean  % 

Mean 

PI 

us  Standard  Deviation  i 

PD/CD  Margin 

0.83 

4.36 

D&B  Margin 

1.71 

5.29 

C.  MOD  Margin 

0.33 

1.43 

GFM  Margin 

0.33 

1.20 
12.2  8% 

KG  Margin 

PD/CD  Margin 

2.67 

6.09 

D&B  Margin 

1.87 

4.97 

C.  MOD  Margin 

0.18 

1.12 

GFM  Margin 

0 

0.34 
12.52% 

Table  5  NAVSEA  Design  and  Life  Cycle  Margins51 

As  regards  cost,  it  is  important  to  consider  the  trends  of  design  resulting  from  margins  and  convergent  design 
because  the  traditional  methods  of  determining  cost  rely  heavily  on  weight  and  major  system  selections. 
Specifically,  traditional  acquisition  cost  estimates  during  design  are  determined  usmg  parametric  analysis  of  weights 
(from  Ships  Work  Breakdown  Structure  (SWBS)  groups)  for  similar  ship  types  of  the  past.  Table  7  shows  top-level 
SWBS  groups  considered  in  early  ship  design  and  cost  analysis.  The  SWBS  groups  represent  an  accounting  method 
that  provides  means  to  estimate  features  of  the  ship  (such  as  weights  and  distribution  of  weights  for  structures, 
support  systems,  etc)  that  cannot  be  explicitly  defined  during  early  design.  Cost  estimating  relationships  (CER's)  are 
applied  to  the  SWBS  weights  to  determine  cost  estimates.  These  weight-based  cost  estimates  may  be  adjusted  for 
specific  shipyards,  known  system  costs,  learning  curves  associated  with  multi-year  contracts  (Figure  9),  and  other 
reasonable  cost  impacts.  Generally,  the  result  of  the  estimates  determined  m  this  manner  should  follow  behavior 
similar  to  the  weight  behavior  of  Figure  6.  i.e.  the  estimate  should  converge   During  later  design  stages,  small 
transfers  of  weight  from  one  SWBS  group  to  another  rv  y  result  in  substantial  first  order  cost  impacts   These 
impacts  can  be  forecasted  early  in  the  design  process  through  sensitivity  analysis  of  the  parametrics  (Table  6.) 
However,  the  second  order  cost  impacts  due  to  disruption,  transitions  within  SWBS  groups  and  multi-ship  schedule 
shifts  are  not  disclosed  with  weight-based  costing''2.  Although  these  impacts  arc  usually  within  20%  of  the 
parametncally  determined  values,  they  can  grow  to  levels  of  well  over  the  initial  cost.53  That  has  been  a  criticism  of 
such  cost  methods.  There  is  a  need  to  improve  the  methodology  of  w  eight-based  costing  to  be  responsive  to  second 
order  effects,  or  new  methods  must  be  used. 


?1  Reuven  Leopold,  Manual  for  Naval  Surface  Ship  Design  Technical  Practices,  Naval  Sea  Systems  Command. 
Washington  DC.  1978,  page  4-157 

52  Kenneth  Cooper.  Naval  Ship  Production:  A  Claim  Settled  and  a  Framework  Built.  Pugh-Roberts  Associates, 
Cambridge.  MA  December  6.  1980. 

53  Prof.  Alan  Brown,  interview  May  11,  1998,  Massachusetts  Institute  of  Technology.  Cambridge.  MA. 
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Ship  Work  Breakdown 
Structure 

Program  Cost 
(FY  83  S/lton) 

100  Structure 

17.500 

200  Propulsion 

1 10,800 

300  Electric 

180,200 

400  Command 

46.300 

500  Auxiliary 

80.800 

600  Outfit 

78,500 

700  Armament 

16.000 

Table  6  Cost/Weight  Sensitivity 
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SWBS 

Description 

SWBS 

Description 

100 

Hull  Structures 

500 

Auxiliary  Systems,  General 

110 

Shell  and  Supporting  Structure 

510 

Climate  Control 

120 

Hull  Structural  Bulkheads 

520 

Sea  Water  Systems 

130 

Hull  Decks 

530 

Fresh  Water  Systems 

140 

Hull  Platforms  And  Flats 

540 

Fuels  and  Lubricants. Handling  and  Storage 

150 

Deck  House  Structure 

550 

Air, Gas  and  Misc  Fluid  Systems 

160 

Special  Structures 

560 

Ship  Control  Systems 

170 

Masts,  Kingposts,  And  Service  Platforms 

570 

Underway  Replenishment  Systems 

180 

Foundations 

580 

Mechanical  Handling  Systems 

190 

Special  Purpose  Systems 

590 

Special  Purpose  Systems 

200 

Propulsion  Plant 

600 

Outfit  and  Furnishings, General 

210 

Energy  Generating  System  (Nuclear) 

610 

Ship  Fittings 

220 

Energy  Generating  Syscem  (Nonnuc) 

620 

Hull  Compartmentation 

230 

Propulsion  Units 

630 

Preservatives  and  Covenngs 

240 

Transmission  and  Propulsor  Systems 

640 

Living  Spaces 

250 

Propulsion  Support  Systems  (Except  Fuel  and  Lube  Oil) 

650 

Service  Spaces 

260 

Propulsion  Support  Systems  (Fuel  and  Lube  Oil) 

660 

Working  Spaces 

290 

Special  Purpose  Systems 

670 

Stowage  Spaces 

690 

Special  Purpose  Systems 

3C0 

Electric  Plant,  General 

700 

Armament 

310 

Electric  Power  Generation 

710 

Guns  and  Ammunition 

320 

Power  Distribution  Systems 

720 

Missies  and  Rockets 

330 

Lighting  System 

730 

Mines 

340 

Power  Generation  Support  Systems 

740 

Depth  Charges 

390 

Special  Purpose  Systems 

750 

Torpedoes 

760 

Small  Arms  and  Pyrotechnics 

770 

Cargo  Munitions 

780 

Aircraft  Related  Weapons 

790 

Special  Purpose  Systems 

400 

Command  and  Surveillance 

800 

Engineering 

410 

Command  and  Control  Systems 

812 

Change  Proposals,  Scoping,  Checking 

420 

Navigation  Systems 

813 

Planning  &  Production  Control 

430 

Interior  Communications 

831 

Construction  Drawings 

440 

Exterior  Communications 

835 

Engineering  Calculations 

450 

Surface  Surveillance  Systems  (Radar) 

838 

Design/Engineering  Liason 

460 

Underwater  Surveillance  Systems 

839 

Lofting 

470 

Countermeasures 

841 

Tests  &  Inspections,  Criteria  &  Procedures 

480 

Fire  Control  Systems 

844 

Combat  Systems  Checkout  Procedures 

490 

Special  Purpose  Systems 

850 

ILS  Engineering 

897 

Project  Management 

Table  7  Ships  Work  Breakdown  Structure 
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Hope  and  Stortz,  "Warships  and  Cost  Constraints",  Naval  Engineers  Journal.  March  1986.  page  45. 
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Another  particular  concern  is  the  increased  dominance  of  combat  system  costs  compared  to  overall  ship  costs. 
Consider  the  trends  shown  in  Figure  8.  The  combat  system  cost  fraction  for  both  combatants  and  amphibious  ships 
are  steadily  increasing.  In  the  years  during  and  following  World  War  II.  combat  systems  consisted  primary  of  high 
density,  heavy-weight  gun  systems.  The  primary'  integration  issues  (and  thus  cost  and  system  trade-offs)  were  gun 
placement  and  provision  for  adequate  displacement  to  support  those  guns  and  their  ammunition.  The  USS  Atlanta 
(CL-51)  is  representative  of  such  designs  (Table  8.)  Its  combat  system  suite  is  consistent  with  other  World  War  II 
designs:  low  cost,  low  technology,  and  highly  redundant.  The  gun  systems  are  manpower  intensive,  but  the 
manpower  is  dominated  by  low  skill,  low  cost  gun  handlers.  The  resulting  ship  has  a  relatively  small  fraction  of 
acquisition  cost  dedicated  to  combat  systems  (less  than  40%),  and  operations  and  support  costs  are  dedicated  to 
supporting  a  young,  unskilled  labor  force.  An  intermediate  generation  of  combatant  ships  (represented  by  the  DD- 
963  class)  falls  in  the  transition  period  for  acquisition  and  design  methodologies,  TPP.  The  combat  systems  are 
more  complex  and  more  expensive  as  a  fraction  of  the  total  cost,  which  also  shows  an  increasing  trend  (Figure  9.)  A 
ship  designed  by  shipbuilders  (Litton-Ingles  Shipbuilding),  it  has  greater  total  volume  to  accommodate  improved 
producibility  and  acceptance  of  future  system  upgrades.  As  a  result  of  these  improvements  and  if  not  for  the 
government  induced  cost  over-runs  (Chapter  1.1.1),  the  ship  acquisition  cost  may  have  been  comparable  to  the  CL- 
5 1 .  Manpower  is  increasingly  skilled  in  electronics,  sensor  management  and  other  specialty  skills.  As  a  result,  the 
ship  is  not  only  increasing  in  combat  systems  cost,  but  also  operations  and  support  costs,  which  are  dedicated  to 
system  maintenance  and  manpower  training.  The  final  generation  of  the  combatant  (DDG-51)  is  the  epitome  of 
current  design  and  cost  trends.  The  combat  system  is  a  very  large  fraction  of  acquisition  cost.  Artificial  constraints 
imposed  on  displacement  and  length,  coupled  with  requirements  to  elevate  large  sensors  on  the  superstructure,  result 
in  a  "beamy",  dense  ship  that  poorly  incorporates  producibility  features.53  Thus,  acquisition  costs  are  undesirably: 
high.  Crew  growth  coupled  with  further  complexities  in  the  combat  system  suite  require  the  most  highly  skilled 
crews  to  operate  and  maintain.  The  result  of  these  factors:  DDG-51  has  pushed  the  combat  system  cost  and  total 
acquisition  cost  trend  to  a  critical  level,  and  operations  and  support  costs  have  exceeded  reasonable  budgetary  levels. 


55  Philip  Sims,  "Ship  Impacts  Studies".  Naval  Engineers  Journal.  Mav  1993.  page  87. 
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Combat  System  Cost  Fraction 
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Figure  8  Combat  System  Cost  Trends 
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Ship 

Atlanta 
CL-51 

Spruance 
DD-963 

Arleigh  Burke 
DDG-51 

Design  Date 

1938 

1969 

1982 

Full  Load  (Iton) 

8440 

7800 

8300 

LBP  (ft) 

530 

529 

466 

Beam  (ft) 

53 

55 

59 

D10(ft) 

33.2 

42 

42 

Volume  (ft3) 

700,000 

1,030,000 

971,000 

Vol  to  Wt  (ft3/lton) 

82.9 

132.1 

117.0 

Crew 

626 

276 

318 

Combat  Cost  Fraction 

40 

47 

57 

Strike  Weapons 

8  x  5738 

2  x  5754 
Harpoon  Missiles 

1  x  5754 
Tomahawk  Missiles 

AAW 

40  &  20  mm  Guns 

NSSM 

SM-2 

Sensors 

Small  radars 
Small  sonar 
Optical 

Medium  radars 
Big  sonars 
Towed  array 

Big  radar 
Big  sonar 
Towed  array 

Table  8  Comparison  of  Combatants  over  Time 


56  RADM  Roger  B  Home.  "Concept  to  Commissioning,  Improving  the  Ship  Design.  Acquisition  and  Construction 
Process:  Strategic  Plan",  Naval  Sea  Systems  Command.  Washington.  DC.  June  1991. 
5  Philip  Sims.  "Ship  Impacts  Studies",  Naval  Engineers  Journal,  Mav  1993,  page  91. 
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Cost  Comparisons  of  Surface  Combatant  Projects 
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Figure  9  Basic  Cost  of  Construction  Trends  for  Surface  Combatants 

As  a  result  of  these  trends,  many  cost  control  programs  have  been  implemented.  First,  weight-based  costing 
has  evolved  greater  fidelity.  The  ACEIT  (Automated  Cost  Estimating  Integrated  Tool)  cost  program  is  a  Joint 
Sen  ice  system  providing  a  suite  of  costing  tools  designed  to  assist  analysts  in  arriving  at  cost  estimates,  conducting 
"what-if  ?"  studies,  developing  cost  proposals  and  evaluations,  conducting  risk  and  uncertainty  analysis,  and 
developing  CER's.  The  program,  developed  and  maintained  by  Tecolote  Research  Inc..  provides  many 
improvements  over  traditional  weight -based  approaches  including'9: 

•  User  defined  WBS  with  capability  to  build  one  or  more  default  WBS  and  associated  definitions. 

•  Ability  of  users  to  enter  their  own  cost  equations,  access  a  built-in  Methodology  Knowledge  Base,  search 
for  analogous  data,  or  create  CER's. 

•  The  calculation  of  basic  learning  curves,  shifts,  rotations,  rate  effects,  simultaneous  sensitivity/"what-if?" 
analyses,  quantity  changes,  adjust  for  lead/lag  times  with  methods  for  time  phasing,  and  adjustments  for 
design  producibility. 

•  Integrated  interface  (AACEI)  with  ship  design  synthesis  tools  (ASSET)  for  real-time  cost-design 
comparison. 


58 


Colton  and  Company,  hup://-u"u  w  .coltoncompam-.com.  Arlington,  VA. 
,9  Defense  Acquisition  Deskbook  Joint  Program  Office.  "Defense  Acquisition  Deskbook,  Version  2.2.87",  Wright- 
Patterson  Airforce  Base.  Dayton,  OH.  December  15,  1997. 
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•  An  automated  cost  database  (ACDB)  with  the  capability  to  enter,  search,  and  retrieve  cost,  schedule, 
technical,  and  programmatic  data,  including  contractor  raw  data  (mapping  and  normalizing  cost  data  into 
standard  WBS). 

•  Cost  analysis  statistical  package  (CO$TAT)  performs  statistical  analyses  including  histograms  and 
scatter  plots,  linear,  log-linear,  and  non-linear  regression,  and  fit  learning  curves,  cost  risk  application 
(RISK)  that  performs  risk  and  uncertainty  analysis. 

The  immediate  goal  of  these  improvements  is  to  provide  ship  design  managers  with  robust  acquisition  cost  estimates 
early  in  the  design  process,  thus  leveraging  design  trade-offs.  However.  ACEIT  fits  within  the  context  of  a  larger 
movement  in  the  DoD:  the  transition  from  acquisition  costs  and  simple  Life  Cycle  Cost  (LCC)  analysis  to  Total 
Ownership  Costs  (TOC.) 

TOC  is  the  attempt  to  assess  system  cost  beyond  the  boundaries  of  the  specific  platform  (or  ship.)  In  addition 
to  LCC  (R&D.  acquisition,  operations  and  support  and  disposal  costs),  TOC  seeks  to  include  appropriate  external 
costs  resulting  from  the  development  of  the  ship  (i.e.  training  pipe-lines,  repair  facility  and  overhead  combat 
systems,  cost  of  a  sailor,  etc.)  TOC  is  incorporated  formally  in  the  design  process  through  the  methodology  of  Cost 
as  an  Independent  Variable  (CAIV)60  Through  the  CAIV  approach,  early  phases  of  the  acquisition  process  (Pre- 
Milestone  I)  establish  an  aggressive,  achievable  LCC  goal  based  on  mission  requirements,  reasonable  delivery 
schedules,  acceptable  design  baselines  and  expected  budgetary  forecasts.  At  Milestone  I.  firm  cost  boundaries  are 
established,  as  well  as  goals  for  LCC  reduction  (the  savings  being  reflected  as  TOC.)  Design  managers  seek  to 
optimize  system  cost,  performance  and  schedule  within  tins  context.  The  key  to  achieving  effective  constraints  and 
goals  is  the  inclusion,  early  in  the  process,  of  all  relevant  life  cycle  participants.  "The  Overarching  IPT  (OIPT)  for 
each  ACAT I  and  ACAT IA  (as  required)  program  shall  establish  a  Cost/Performance  IPT  (CPIPT).  The  user 
community  shall  have  representation  on  the  CPIPT.  Industry  representation,  consistent  with  statute  and  at  the 
appropriate  time,  shall  also  be  considered."61  The  inclusion  of  these  participants  at  the  earliest  design  stages 
provides  cost  estimators  the  ability  to  assess  the  impact  on  cost  of  critical  design  decisions  such  as  producibility. 
combat  system  design  schedules,  integrated  logistics  support  (ILS)  and  other  LCC  issues.  Thus,  important  impacts 
can  be  tested  in  cost  models  like  ACEIT. 

Cost  and  the  optimization  of  cost  goals  has  dominated  the  reforms  seen  in  the  last  decade,  particularly  as  seen 
DoD  directives  (CAIV  in  DoD  5000.)  The  evolution  of  cost  models  along  with  greater  inclusion  of  life  cycle 
participants  is  allowing  design  leverage  at  the  point  of  greatest  effectiveness,  early  design.  However,  the  question 
remains. .  will  these  enhancements  effect  only  cost,  or  will  the  dynamic  impacts  of  cost  analysis  result  in 
performance  degradation  and  cycle  time  growth? 


50  "DoD  Directive  5000. 2-R.  Mandatory  Procedures  for  Major  Defense  Acquisition  Programs  and  Major  Automated 
Information  Svstem  Acquisition  Programs".  Part  3  Section  3.3.3. 


61  Ibid 
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1 .2       Dynamic  Modeling  of  the  Design  Process 
1 .2.1      Need  for  Modeling 

The  concerning  trends  reflected  in  the  DAC  study,  increasing  costs  and  schedule  with  lack  of  system 
performance  assessment,  have  received  substantial  focus  and  improvement  efforts.  For  cost,  improved  cost  models 
and  greater  inclusion  of  life  cycle  participants  have  highlighted  "stalking  horses"  that  may  be  tamed  to  reduce  costs. 
As  for  performance,  greater  customer  focus  within  the  context  of  improved  system  requirement  and  performance 
assessment  provides  better  means  to  trade  performance  against  factors  of  cost  and  schedule.  Even  cycle  time  may 
realize  significant  improvements  with  the  inclusion  of  IPTs,  evolving  acquisition  strategies,  and  computer  based 
data  management  and  assessment.  However,  unlike  cost  and  performance,  naval  design  process  time  has  not 
received  mush  effort  towards  the  creation  of  robust,  strategic  assessment  tools.  Naval  design  managers  lack  the 
ability  to  effectively  trade-off  schedule  with  process  improvements.  This  shortcoming  is  important  considering  the 
three  primary  variables:  cost,  performance  and  schedule.  The  difficulty  in  managing  a  successful  program  results 
from  the  fact  that  "...the  vectors  of  these  variables  are  highly  interdependent  and  non-lmear."6:  As  noted 
previously,  the  improvements  to  costing  and  performance  naturally  impact  the  schedule  through  inclusion  of  new 
design  participants,  increasing  levels  of  desired  design  tasks  early  in  the  process  or  introduction  of  previously 
unused  or  unavailable  assessment  tools. 

Traditional  project  modeling  tools,  such  as  PERT  and  CPM.  do  provide  a  tool  for  assessing  the  direct  impacts 
of  such  changes,  but  often  fail  to  capture  critical  feedback  and  dependencies  within  the  engineering  and  production 
process.63  As  a  modeling  technique,  system  dynamics  can  effectively  capture  such  non-linearity  and  thus,  provide 
better  understanding  of  the  modulations  of  the  v  ariables  under  consideration  With  respect  to  project  management, 
system  dynamics  has  been  proven  for  numerous  specific  applications  and  cases.64  However,  system  dynamics  has 
been  primarily  used  for  high  level  or  very  specific  decisions  and  often  lacks  sufficient  structural  detail  to  apply  to  a 
specific  process  (such  naval  design.)65 

A  need  has  developed  to  provide  program  managers  mth  a  dynamic  process  tool  appropriately  adjusted  to 
reflect  the  realities  of  naval  design. 


62  ADM  Wayne  Meyers  (USN  ret),  interview,  Techmatics  Inc..  Arlington.  VA  November  13.  1997. 

63  Rodrigues  and  Bowers,  "System  Dynamics  in  Project  Management:  a  Comparative  Analysis  with  Traditional 
Methods'.  Svstem  Dynamics  Review.  Volume  12  Number  2,  summer  1996,  page  130. 

64 


Ibid,  page  128 
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65  Ibid,  page  133. 


1.2.2      What  is  System  Dynamics? 

System  dynamics  is  rooted,  like  its  founder  Dr.  Jay  W.  Forrester66,  in  the  engineering  traditions  of  control 
theory  and  feedback  analysis.  Three  characteristics  distinguish  system  dynamics  from  traditional  management 
support  tools6  : 

•  Its  foundation  is  engineering  science,  not  statistics, 

•  It  relies  on  data  to  support,  not  control  model  development,  and 

•  It  presents  a  dynamic,  not  static,  environment  for  decision  analysis. 

Specifically,  system  dynamics  emphasizes  the  construction  of  models  that  capture  the  process  of  a  system  based  on 
explicit  casual  relationships  of  variables  within  a  closed-loop  feedback  structure.  Data  is  used  to  calibrate  the 
model,  but  the  verification  of  a  model  relies  on  common  sense  (agreement  of  the  operation  of  the  real  world  and  the 
model  structure)  and  formal  mathematics  (accumulations  and  flows  based  in  differential  calculus.)  The  resulting 
model  relies  on  complex,  non-linear  relationships  to  dictate  behavior,  rather  than  linear,  statistically  based 
associations.  System  dynamics  models  still  incorporate  statistics  during  analysis  as  a  means  to  test  the  sensitivity  of 
model  assumptions.  But  tins  analysis  is  intended  to  further  validate  the  model  rather  than  drive  model  development. 
Finally,  model  results  are  meant  to  be  used  as  strategic  tools  to  compare  policy  impacts,  not  produce  explicit  results 
(such  as  exact  cost  or  a  definitive  time  table  )  A  validated  model,  which  demonstrates  generally  accurate  behavior 
(variable  fluctuations,  dynamic  convergence  or  divergence,  and  representative  process  structure)  provides  a  means 
to  assess  policy  options  for  "order  of  magnitude"  relationships. 

System  dynamics  is  widely  accepted  as  an  assessment  tool.  During  the  late  1950's.  Dr.  Forrester,  an  MJT 
researcher  responsible  for  the  invention  of  random-access  magnetic  computer  memory,  accepted  a  position  with  the 
Sloan  School  of  Management.  His  interest  was  the  application  of  control  theory  to  social  systems  such  as  business 
and  industrial  processes.  Since  that  time,  his  analytic  approach  has  blossomed  into  an  accepted  field  of  social  policy 
analysis  with  numerous  successes  including: 

•  Urban  Dynamics,  a  study  of  the  policy  impacts  of  urban  housing  developments, 

•  Limits  to  Growth,  a  study  of  earth's  ability  to  sustain  mankind  under  current  environmental  trends. 

•  The  National  Economic  Model,  a  study  of  business  cycles  in  the  United  States,  and 

•  numerous  business  and  social  process  models. 

These  models,  as  well  as  previously  mentioned  models  (1.1.1  and  1.1.2),  are  particularly  useful  in  their  ability  to 
show  why  a  seemingly  useful  organizational  policy  fails  to  produce  the  results  expected  from  policy  managers. 
For  example.  Analog  Devices  Inc  (ADI)  of  Norwood.  Massachusetts,  a  producer  of  high-end  integrated 
circuits  successfully  applied  a  Quality  Improvement  Program  to  their  production  process.68  The  goal  of  the  program 
was  the  improvement  of  product  quality  (reduction  of  errors),  on-time  delivery  and  reduction  of  production  cycle 


66  Jay  W.  Forrester.  "The  Beginning  of  System  Dynamics",  banquet  talk  at  the  international  meeting  of  the  System 
Dynamics  Society.  Stuttgart.  Germany,  July  13,  1989. 

5  Dr.  Louis  Alfeld.  "The  System  Dynamics  Modeling  Methodology".  Decision  Dynamics  Inc,  1994, 
www  decisiondynamics.com. 

d8  Robert  Kaplan,  "Analog  Devices:  The  Half-Life  System",  Harvard  Business  School  case  study.  1990 
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time.  The  improvement  process  found  great  success  on  the  production  floor  within  a  very  limited  time  (2  years.) 
However,  when  management  attempted  to  apply  their  program  to  product  development,  it  not  only  failed,  it  began 
negatively  impacting  the  production  cycle.  A  system  dynamics  model  was  generated  and  showed  managers  that 
failure  to  adjust  the  improvement  program  goals  relative  to  the  time  scales  of  production  versus  development  had 
generated  the  failure.  Human  intuition  (if  the  improvement  was  effective  in  production  it  should  be  effective  in 
development)  failed  to  understand  the  dynamics  of  how  the  improvement  process  disseminated  through  the 
organization  and  how  the  various  sectors  of  the  organization  are  inter-related.  System  dynamics  is  effective  at 
showing  these  process  factors. 

1.2.3      Modeling  Approach  and  Structure 

The  procedure  for  developing  and  analyzing  a  system  dynamics  model  is  well  stated  by  Randers.69  The 
procedure  is  applied  in  four  stages: 

1 .  Conceptualization 

2.  Formulation 

3 .  Testing 

4      Implementation 
With  respect  to  the  naval  design  model,  stage  1  is  discussed  in  Chapters  1-4  and  stage  2  in  Chapter  5.  Stage  3  is 
presented  for  a  few  select  cases  in  Chapter  6  and  stage  4  will  be  considered  for  future  application  in  Chapter  7. 

Specifically,  stage  1  invokes  the  consideration  of  the  problem  to  be  studied  (as  stated  in  Chapter  1.1.1  page 
13).  temporal  behavior  of  important  variables  in  the  problem  (such  as  presented  in  Figure  1  Combatant  Cycle  Time 
Trends)  and  hypothesis  of  casual  mechanisms  within  the  studied  process.  To  this  end,  the  naval  design  model 
examines  factors  external  to  the  design  process  for  a  single  surface  combatant  program  (budgeting,  performance 
changes,  design  resource  availability  within  the  context  all  naval  design  projects.)  However,  these  factors  are  not 
explicitly  modeled,  rather  assumed  as  exogenous  inputs  to  the  model.  Endogenous  model  elements  include  physical 
design  task  flows,  design  organization  relative  to  design  resources,  design  decision  processes  and  cost  constraints  to 
the  design  process. 

Stage  2  presents  a  specific  model  for  a  surface  combatant  design  program  (DDG-51  program.)  The  model 
builds  on  elements  of  previously  developed,  system  dynamics  models.  Tins  approach  enhances  mathematical 
accuracy  of  the  model  as  well  as  validity  relative  to  accepted  modeling  practices.  However,  the  selected  model 
elements  are  tailored  to  the  behavior  modes  expressed  in  stage  1 .  In  particular,  the  model  reflects  the  impact  of 
naval  design  task  inter-relationsmps  based  on  the  design  spiral  (Chapter  4.) 

Stage  3  demonstrates  the  model  calibrated  to  the  DDG-51  Program  (August  1978  through  September  1991.70) 
Given  replication  of  baseline  behavior  by  the  model,  several  "What  if'  scenarios  are  proposed: 


69  Jorgen  Randers.  'Guidelines  for  Model  Conceptualization",  Elements  of  Svstem  Dynamics  Method.  MIT  Press. 
Cambridge,  MA  1980. 

70  Ship  Design  Group.  Ship  Design  Project  Histories  Volume  II  1980-1989.  Naval  Sea  Systems  Command  May 
1986.  pages  2-8. 
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1.  Application  of  3-D  Product  Models  and  Simulation  Based  Design,  and 

2.  Application  of  Integrated  Product  Teams  and  Concurrent  Engineering. 

The  results  of  these  scenarios  provide  relative  assessment  of  the  improvement  processes  for  consideration  against 
accepted  "mental  models"  of  how  those  processes  should  effect  the  process. 

Finally,  stage  4  discusses  the  future  uses  of  the  model  as  a  tool  specific  to  surface  combatant  programs  (like 
the  DD-2 1  program)  when  continuously  calibrated  and  adjusted  as  process  improvement  results  are  available  or 
alternative  "what-if  "s  are  asked.  As  such,  the  model  is  proposed  for  use  as  a  "management  flight  simulator"  in 
naval  design  programs.  The  model  may  further  be  incorporated  into  the  structure  of  larger  models  addressing 
complete  life-cycle  (design  through  production  through  operations  and  support)  and  cross-programmatic  (budget 
allocation  and  project  phasing)  issues.  Finally,  the  model  is  considered  for  its  potential  role  as  a  piece  of  a  larger 
"cost-schedule-performance"  model 
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2       Design  Process  External  Influences 

When  first  analyzing  the  problem  of  cycle  time  growth,  it  is  necessary  to  understand  the  external  influences 
that  constrain  and  drive  the  design  process.  The  externalities  generally  consist  of  strategic  variables  and  decisions 
such  as  total  force  structure  and  capability  (order  of  battle),  national  defense  budget  and  budgetary  allocations,  threat 
capabilities  and  capability  differentials  (gap  between  our  force  and  an  enemy.)  These  externalities  play  a  critical 
factor  in  cycle  time  growth.  As  such,  the  only  true  method  to  reverse  cycle  time  trends  is  to  understand  and  control 
the  forces  of  the  externalities.  However,  changes  to  the  overall  acquisition  and  force  structure  are  not  within  the 
scope  of  this  thesis.  Rather,  the  goal  is  to  establish  a  model  representative  of  internal  process  forces,  such  that 
improvements  proposed  to  the  internal  structure  can  be  assessed.  Therefore,  we  will  examine  the  external  influences 
to  recognize  their  impact  on  the  design  process  as  exogenous  inputs,  leaving  external  analysis  and  decisions  to 
alternate  forums.  By  understanding  the  effect  of  external  forces,  the  internal  process  can  be  designed  to  minimize 
their  impact. 

The  following  influence  diagram.  Figure  10.  shows  a  number  of  the  important  reinforcing  and  balance  loops 
which  ultimately  effect  the  design  process.  The  loops  represent  those  cause  and  effect  mechanisms  that  act  in 
concert  with  and  as  feedback  to  many  of  the  behaviors  apparent  in  the  process  of  budgeting,  setting  requirements 
and  managing  schedules.  The  loops  are  influenced  by  a  combination  of  observed  temporal  variations  (behavior 
modes),  physical  responses  (decision  policies  and  mechanisms)  and  structures  required  to  close  feedback  processes. 
In  particular,  note  the  mechanisms  influencing  "Design  and  Acquisition  Rate"  (instantaneous  design  cycle  time.) 
The  rate  is  impacted  by  resource  availability,  acceptable  risk  levels  and  design  complexity'.  The  variables  shown 
aggregate  many  variables  (design  and  acquisition  rate  represents  the  average  rate  for  all  current  design  projects.) 
The  diagram  also  establishes  boundaries  (primarily  encompassing  naval  ships)  that  could  easily  be  expanded  or 
contracted  to  capture  additional  trends. 

These  dynamics  represent  a  series  of  dynamics  specifically  noted  by  naval  process  experts  during  interviews 
held  August  24-28.  1997,  November  12-14  and  19,  1997  and  December  8-11,  1997.  The  interviews  included 
government  design  managers  and  engineers  (NAVSEA  and  Naval  Surface  Warfare  Center  Carderock  Division), 
commercial  design  support  and  shipbuilders  (John  J  McMullen  and  Associates.  Techmatics  Inc.  SYNTEK  Inc.. 
Newport  News  Shipbuilding,  and  Bath  Iron  Works)  and  academia  (MIT  and  Sloan  School  of  Management.)  A 
complete  listing  of  personnel  interviewed  can  be  found  in  Chapter  8.2. 

The  dynamics  are  examined  individually  to  clarify  their  inclusion  in  the  totality  of  external  process 
influences. 
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2.1       Reciprocity  and  Proliferation... the  Need  for  Naval  Capabilities  Evolution 

In  his  1996  thesis  on  the  naval  ship  production  process71,  Tim  McCue  introduced  the  concept  of  the  'Arms 
Race  Dynamic."  This  dynamic  is  shown  in  Figure  11.  There  are  two  dynamic  loops  at  work  in  this  process:  the 
Proliferation  Dynamic  and  the  Reciprocity  Dynamic.  The  Proliferation  Dynamic  is  well  understood  by  military 
strategists  and  is  a  source  of  debate  with  respect  to  international  control  of  weapons  and  capabilities  (particularly 
weapons  of  mass  destruction  and  'smart  weapons".  2)  The  Proliferation  Dynamic  is  a  'snowballing  dynamic"  and 
may  be  characterized  as  follows: 

1 .  As  new  weapons  and  doctrines  are  introduced  into  service  by  US  forces,  these  capabilities  will  diffuse 
(or  proliferate)  over  time  such  that  threat  forces  possess  reciprocal  capabilities  (either  equivalent  or 
negating) 

2.  As  proliferation  carries  on.  US  intelligence  methods  will  characterize  the  threat  based  on  actual  and. 
consequentially,  perceived  capability  of  the  threat  force 

3.  The  perceived  threat  will  be  weighed  against  US  capabilities  resulting  in  a  US  advantage  (or  deficiency) 

4.  As  proliferation  continues,  the  US  advantage  will  decline  and  pressures  to  enhance  US  capabilities  will 
begin  to  increase 

5.  As  pressures  to  enhance  capabilities  increase,  the  US  forces  will  improve 

6      Force  improvements  will  be  noted  by  the  threat  force  that  will  in  turn  seek  to  gain  the  same  enhanced 
capability  or  a  negating  capability . . .  and  so  on. 
The  Proliferation  Dynamic  has  many  other  details  not  noted  here  (such  as  cost  of  new  capabilities,  technological 
complexity  and  political  landscape)  which  have  significant  impact  on  the  rate  of  proliferation.  However,  time  has 
shown  that  proliferation  rate  may  be  moderated,  but  as  long  as  inequalities  exist  diffusion  will  occur 


1  Timothy  P  McCue.  "The  Dynamics  of  Naval  Shipbuilding-a  Systems  Approach".  Department  of  Ocean 
Engineering  Thesis,  Massachusetts  Institute  of  Technology,  June  1997. 
:  William  S.  Cohen.  Report  of  the  Quadrennial  Defense  Review.  United  State  Department  of  Defense.  May  1997. 
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Actual  Naval  Threat 


US  Naval  Order  of  Battle  (OMOE) 


Complexity  of  Design 


Design  &  Acquisition  Rat- 


Figure  11  Arms  Race  Dynamic 

In  order  to  balance  the  threat  of  Proliferation.  US  forces  must  follow  with  Reciprocity.  The  Reciprocity 
Dynamic  is  characterized  as  follows: 


US  forces  start  at  a  given  force  level  (US  Naval  Order  of  Battle) 

The  US  force  has  an  inherent  capability  advantage  (or  deficit)  when  compared  to  potential  threat  levels 
Pressures  to  increase  US  capability  (typically  political)  increase  as  the  US  advantage  is  decreased 
The  source  of  new  military  advantages  may  originate  from  new  capabilities  (new  ships,  weapons,  etc.)  or 
changes  to  enhance  doctrine  to  employ  current  forces 
5.     Capabilities  increase  the  US  advantage  until  pressure  to  improve  is  nullified. 
As  with  Proliferation.  Reciprocity  can  be  further  described  by  additional  variables  such  as  current  political  climate, 
defense  costs  and  the  state  of  the  US  economy,  or  perceived  level  of  international  stability.  However,  as  long  as  the 
US  continues  to  choose  a  role  as  a  leader  in  world  affairs,  military  strength  (advantage)  will  likely  be  the  doctrine  of 
choice. 

Two  detailed  expansions  of  the  Arms  Race  Dynamic  are  also  demonstrated.  First,  the  new  construction 
dynamic  demonstrates  that  one  method  of  increasing  capability  is  to  develop  new  weapon  and  slup  systems  The 
construction  of  new  designs  (increased  with  increasing  design  rates,  measured  as  new  designs  completed  over  time) 
results  in  the  increased  order  of  battle. .  completing  the  reciprocity  balancing  force.  A  second  dynamic  expansion  is 
the  impact  of  technology  from  proliferation    As  proliferation  of  advanced  defense  technologies  occurs,  the 
complexity  of  new  designs  required  to  counter  those  technologies  increase.  As  complexity  is  increased,  the  design 
rate  slows  (more  time  is  required  to  gain  equivalent  leaps  in  performance  advantage),  new  constructions  slows  and 
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the  order  of  battle  decreases. .  ultimately  the  ability  to  maintain  capability  advantage  will  be  lost  to  the  balancing 
force  of  technological  complexity. 

The  'Arms  Race  Dynamic"  lies  at  the  heart  of  the  Naval  Design  Process  as  the  primary  influence  effecting 
the  need  for  new  designs,  the  need  to  support  operating  forces,  the  increasing  complexity  of  newer  designs  and  the 
acceptable  levels  of  risk  relative  to  cost,  performance  and  cycle  time.  Consider  Figure  12.  Correlated  against  the 
trends  shown  in  Figure  1  and  Table  8.  US  warships  have  been  dedicating  larger  fractions  of  procurement  costs  to 
combat  systems  in  response  to  ever  growing  threats,  while  the  combat  systems  themselves  are  achieving 
exponentially  decaying  improvements  in  capability,  and  the  net  development  cycle  is  slowing  to  accommodate 
assessment  of  the  threat  and  development  of  systems  capable  of  countering  those  threats.  As  long  as  new  threats  are 
generated  and  the  US  chooses  to  counter  those  threats,  the  cycle  will  continue  to  generate  the  need  for  a  non-zero 
design  and  acquisition  rate. 


Ship/Weapon  Reaction  Times 
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Figure  12  Naval  Surface  Combatant  AAW  Reaction  Time  Trends 
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2.2       "Order  of  Battle"  Dynamics... Maintaining  Force  Levels 

This  second  dynamic  both  drives  the  need  for  new  designs  and  counters  the  ability  to  produce  new  designs. 
Shown  in  Figure  13,  the  'Order  of  Battle"  dynamic  demonstrates  the  mechanisms  by  which  even  a  static  threat 
ultimately  requires  creation  of  new  designs.  First,  consider  the  "Graying"  Fleet  Dynamic.  For  a  static  capability' 
level,  time  eventually  degrades  the  capability    For  Example: 


Prof.  Charles  Calvano.  Total  Ship  Systems  Engineering,  http://yyeb.npgs.navy.mil. 
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1 .  The  current  US  aircraft  carrier  capability  is  known  (Figure  14). 

2.  The  desire  for  the  US  to  engage  specific  commitments  (Persian  Gulf,  Adriatic  or  South  China  Sea) 
results  in  carriers  being  assigned  to  the  regions. 

3.  As  commitments  increase  for  the  fixed  number  of  carriers,  the  average  aging  process  for  those  committed 
carriers  increases. 

4.  As  carriers  age,  the  useful  life  is  expended  until  decommissioning.  This  increases  the  average  age  of  the 
total  fleet  but  at  the  cost  of  reducing  the  overall  order  of  battle. 

5.  Finally,  as  the  age  of  ships  increases  and  fewer  are  available  due  to  decommissioning  or  increased 
maintenance  time  for  older  vessels,  the  order  of  battle  decreases. . . 

These  balancing  forces  (meeting  commitments  ultimately  means  not  meeting  commitments)  are  reversed  by  the 
counter-balance  of  the  reciprocity  dynamic.  This  is  one  of  the  factors  currently  driving  the  CVX  program  to  replace 
aging  carriers  (Figure  14.) 

An  additional  dynamic  proceeds  from  the  "'Graying"  Fleet  dynamic. .  Fleet  Demand  Dynamic.  By  this 
dynamic: 

1 .  Increased  fleet  age  (as  a  result  of  time  and  increasing  commitments)  generates  pressure  from  operating 
forces  to  devote  funds  to  maintenance  and  support  of  operating  ships 

2.  The  pressure  increases  as  the  total  force  level  increases  and  limited  funds  are  allocated  across  a  larger 
inventory  of  operating  vessels 

3.  The  pressure  translates  as  an  increased  demand  on  engineering  resources  (commercial  and  naval)  to  be 
dedicated  to  fleet  support  vice  development  activities. 

4.  The  pressure  forces  increased  operation  and  support  (O&S)  expenditures  within  the  fixed  constraint  of 
total  available  defense  budget. 

5.  The  increase  of  fleet  support  resources  and  O&S  expenditures  reduces  available  funding  for  development 
projects. 

6.  The  increase  of  fleet  support  resources  and  O&S  expenditures  improves  the  Order  of  Battle  which 
increases  naval  commitments  covered, 

7.  Ultimately  increasing  the  average  age  of  vessels. . . 

The  result  is  reinforcing  behavior. .  aging  ships  demand  resources  to  maintain  force  levels  which  demand  more 
resources  and  so  on.  This  behavior  fueled  much  of  the  deficit  spending  required  to  supported  the  defense  build-up 
of  the  1980s. 

A  third  behavior  has  been  especially  apparent  in  the  last  few  years,  a  trend  to  pay  for  newer  capabilities  with 
the  decommissioning  of  older  vessels.    "Pay  with  Past"  dynamic.  Consider  the  following  trends: 

1 .  For  a  given  force  level  (order  of  battle)  decommissionings  may  be  considered  to  reduce  O&S 
expenditures. 

2.  As  more  ships  are  decommissioned  O&S  expenditures  decrease  which  increases  funds  available  for 
procurement  (R&D  and  SCN), 
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3.  Allocations  of  procurement  funds  to  industry  and  government  resources  result  in  a  pool  of  Engineering 
and  Acquisition  Resources. 

4.  As  this  pool  increases  the  design  rate  (new  designs  produced  over  time)  increases  and  new  designs  and 
acquisitions  result, 

5.  Ultimately  increasing  the  order  of  battle  in  the  form  of  new  ships  and  capabilities. 

This  behavior  is  balancing...  decreasing  order  of  battle  with  decommissioning  will  increase  order  of  battle  with  new 
construction.  During  the  down-sizing  of  the  1990's,  many  new  construction  programs  and  upgrades  to  operatmg 
units  were  funded  with  the  decommissioning  of  older  vessels.  However,  the  majority  of  the  recovered  funds  were 
lost  to  a  shrinking  defense  budget  and  increases  in  O&S  funds  required  for  support  of  US  commitments  (Somalia, 
Haiti,  Bosnia,  Persian  Gulf,  etc.) 

A  final  behavior  of  note  is  the  Industrial  Demand  Dynamic.  Proposed  by  Dr  Harvey  Sepulski74 
(Massachusetts  Institute  of  Technology),  this  dynamic  has  received  significant  focus  from  the  defense  industry  in 
recent  years: 

1.  If  allocations  for  contracted  resources  decreases  (due  to  decreasing  defense  budget  funds),  there  is 
increased  pressure  from  industry  (on  Congress  and  on  government  acquisition  authorities)  to  privatize 
government  operations 

2.  As  pressure  increases,  greater  portions  of  funds  are  given  to  industry, 

3 .  The  increased  allocation  to  industry  decreases  pressure  for  privatization . . . 

The  result  is  a  balancing  force  within  the  defense  industry  with  respect  to  available  defense  funds.  Note  that 
increasing  privatization  must  be  coupled  with  decreased  in-house  resources  for  a  fixed  budget. 

The  dynamics  of  these  Order  of  Battle  factors  impacts  the  design  rate  through  fund  allocations  (giv  ing  and 
taking  from  development  programs)  and  as  factors  requiring  the  introduction  of  new  forces  to  replace  older  ships. 
Many  of  these  dynamics  are  currently  being  examined  by  industry  as  potential  areas  for  privatization  of  fleet  support 
expenditures.  5 


74  Presentation  to  Ocean  Systems  Special  Project  course  at  Massachusetts  Institute  of  Technology.  Spring  1997. 
3  Prof.  Jim  Hines,  Applications  of  System  Dynamics  course  project  supporting  the  Boeing  Corporation.  Sloan 
School  of  Management.  Cambridge,  MA  Spring  1998. 
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Figure  13"0rder  of  Battle"  Dynamics 
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Figure  14  Timeline  for  US  Aircraft  Carrier  Development  and  Decommissioning 

2.3       Design  &  Acquisition  Rate  Influences 

The  cycles  of  the  Arms  Race  and  Order  of  Battle  are  shown  to  demonstrate  their  influence  over  the  topic  of 
primary  concern:  Design  Rate.  In  particular,  it  is  important  is  understand  how  these  d> Tiamics  control  design  rate 
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(and  thus,  design  cycle  time)  through  the  functional  input  of  performance  and  cost.     Figure  15  shows  an  expanded 
view  of  these  inputs.  It  has  already  been  shown  implicitly  that  design  rate  is  impacted  by  changes  taking  place  in 
cost  and  performance  (Chapters  1.1.2  and  1. 1.3)  as  well  as  by  the  dynamics  of  performance  requirements  (Chapter 
2. 1)  and  cost  constraints  (Chapter  2.2.)  Design  rate  is  also  explicitly  impacted  by  cost  and  performance  constraints. 
Consider  the  case  of  the  DDG-51  program.  During  the  preliminary  and  contract  design  process,  design  managers 
applied  an  approach  of  a  "closed  loop  feedback  control  process  of  establishing  budgets,  reviewing  the  design  for 
conformance  to  the  budgets,  and  making  decisions  to  change  the  design  (within  performance  constraints)  where 
design  features  exceeded  the  established  budget."76  Figure  16  demonstrates  this  form  of  "dynamic  cost  control" 
with  an  exponential  increase  in  cost  from  an  initial  baseline  through  the  end  of  the  Feasibility  Design  Phase 
followed  by  a  very  rapid  oscillation  beginning  in  May  1983  to  stabilize  the  cost  ($700 M  follow-ship  acquisition  cost 
in  FY83$.)  Coincidentally,  May  1983  represented  the  official  start  of  the  Contract  Design  Phase ...  a  period  during 
which  cost  becomes  very  apparent  and  engineering  manpower  rapidly  ramps-upward  to  facilitate  increasing  design 
tasks   .  The  result  of  this  process  was  a  lengthening  of  the  design  schedule  by  several  months  to  accommodate  the 
additional  analysis  and  review.78 
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Figure  15  Design  Rate  Dynamic  Inputs 


6  Hope  and  Stortz,  "Warships  and  Cost  Constraints'".  Naval  Engineers  Journal.  March  1986.  page  43. 

7  Ship  Design  Group.  Ship  Design  Project  Histories  Volume  II  1980-1989.  Naval  Sea  Systems  Command.  May 
1986.  pages  2-8. 

78  Hope  and  Stortz.  "Warships  and  Cost  Constraints".  Naval  Engineers  Journal.  March  1986,  page  46. 
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Contract  Design-Cost  Trends 
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Figure  16  DDG-51  Contract  Design  Procurement  Cost  Estimate  Trend 

These  inputs  and  cycle  time  dynamics  are  explained  by  the  following  influences: 

1 .  Increases  in  design  complexity  (performance  required)  lengthen  the  design  process  (slow  the  design  rate) 

2.  Decreases  in  design  funds  and  engineering  resources  lengthen  the  design  process  as  acquisition 
authorities  become  risk  adverse  (hesitant  to  commit  funds)  and  basic  resources  become  diluted  among 
design  projects 

3.  As  perceived  threats  from  proliferation  and  decreasing  US  advantage  become  apparent,  pressures  to 
increase  design  rate  (shorten  cycle  time)  come  from  reduced  schedules  and  willingness  to  accept  greater 
design-performance  risk 

4.  Finally,  as  the  volume  of  designs  in  progress  mcreases,  the  rate  naturally  adjusts  (balancing)  as  schedules 
for  immature  designs  are  relaxed  to  focus  resources  on  designs  in  the  later  stages  of  completion. 

These  influences  represent  the  input  variables  that  must  be  considered  for  inclusion  in  a  design  process  model. 
However,  these  variables  are  external  to  a  specific  design  project.  Although  a  design  manager  must  consider  issues 
such  as  increasing  performance  requirements  or  reduced  funding  from  the  defense  budget,  he  has  little  control  over 
budget  allocations  to  other  programs  or  the  cancellation  of  a  technology  pipeline  by  a  sister  service  in  the  DoD.  As 
such,  these  variables  are  included  as  exogenous  inputs  to  the  model    The  model  provides  a  means  to  change  the 
assumptions  of  the  inputs,  thus  allowing  the  gaming  of  potential  scenarios  driven  by  those  influences. 


79  Vernon  E.  Stortz,  "DDG-51  Design-Cost  Trend  Log",  unpublished.  Naval  Surface  Warfare  Center  Carderock 
Division,  Bethesda.  MD,  August  1984. 

44 


3       Design  Process  Dynamics 

3.1       Systems  Engineering  and  Naval  Ship  Design 

The  naval  ship  design  process  is  the  process  of  establishing  a  military  need,  defining  this  need  in  terms  of 
military  requirements  and  constraints,  performing  a  set  of  design  tasks  to  develop  a  solution,  validating  the  solution 
versus  the  requirements,  and  translating  the  solution  into  a  form  usable  for  production  and  ship  support.  Figure  17 
demonstrates  this  concept  and  it's  iterative  elements.  These  steps  are  repeated  at  each  stage  of  the  design  process, 
from  concept  to  production  design,  with  the  detail  of  the  tasks  increasing  concurrently  with  the  maturity  of  the 
design. 
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Figure  17  Systems  Engineering  Process80 

The  dominant  accumulations  and  flows  in  this  generic  process  are  as  follows: 

1 .  Input  requirements  generation  (such  as  threat  analysis  and  Mission  Need  Statement  (MNS)  generation) 
with  tasks  for  analysis  of  mission  needs 

2.  Functional  analysis  tasks  (such  as  Industrial  Base  Assessment  and  Analysis  of  Alternatives)  that  establish 
reasonable  system  options 

3.  Synthesis  tasks  (such  as  hullform  design  or  combat  systems  integration)  that  define  and  optimize  the 
system 

4      Evaluation  and  decision  (such  as  ship  vulnerability  modeling  or  milestone  approvals)  with  tasks  to 
examine  and  approve  or  disapprove  completed  design  tasks,  and 

5.     Description  of  System  Elements  (such  as  Contract  Specifications  or  Construction  Drawings)  to  translate 
system  requirements  into  component  and  production  specifications 

Several  important  feedback  flows  are  apparent  in  the  process.    Iterations  may  result  from  physical  design 
balance,  design  errors,  risk  mitigation,  scope  change,  and  modification  of  input  requirements.  Physical  convergence 
is  centered  on  design  synthesis. 

Synthesis  in  naval  ship  design  is  modeled  in  the  design  spiral.  The  dynamics  of  spiral  concurrence  and 
information  transfer  are  a  unique  property  of  naval  ship  design.  A  more  detailed  discussion  is  presented  in  Chapter 
4 


KockJer.  Withers.  Poodiack  and  Gierman,  Systems  Engineering  Management  Guide.  Defense  Systems 
Management  College.  January  1990,  page  1-3  and  5-2 
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An  important  source  of  feedback  is  error  discovery  and  correction.  Errors  themselves  may  be  generated  at 
any  stage  of  the  process.  Early  in  the  process,  errors  occur  when  objectives  and  requirements  are  erroneously  or 
imperfectly  specified.  The  mechanisms  described  m  Chapter  1. 1.2  are  designed  to  mitigate  the  probability  of  errors 
in  these  stages.  During  later  stages,  errors  may  be  caused  by  communication  disruptions  (design  hand-off s). 
misinterpretation  of  specifications,  inaccuracies  or  singularities  in  design  algorithms  (computational  inaccuracies, 
design  modeling  assumptions  or  discontinuities  in  design  variables),  and  human  factors.81 

Error  detection  and  management  typically  occurs  during  specific  Quality  Assurance  (QA)  stages.  QA  is 
defined  as  "a  set  of  activities  performed  in  conjunction  with  a  (project)  to  guarantee  the  product  meets  the  specified 
standards. .  these  activities  reduce  doubts  and  risks  about  the  performance  of  the  product  in  the  target 
environment.*'82  As  errors  are  detected,  the  deficient  tasks  are  returned  to  an  appropriate  stage  for  correction.  As 
demonstrated  in  Figure  17.  error  correction  typically  returns  to  synthesis.  For  this  reason,  it  is  possible  that  the 
correction  stage  may  not  be  the  source  of  the  error,  thus  providing  the  potential  for  future  error  generation    Note 
that  this  is  a  reason  for  the  emergence  of  Total  Quality  Leadership  (TQL)  within  the  Navy  as  a  method  to  analyze 
errors  and  then  causes. 

A  final  source  of  iteration  is  the  modification  of  requirements  and  functional  analysis  products  resulting  from 
evaluated  designs.  These  modifications  can  include  design  changes  (failure  of  the  current  design  to  meet 
requirements)  or  changing  requirements  themselves  (necessitated  by  cost  or  performance  trade-offs.)  Additionally, 
as  the  project  proceeds  through  time,  the  requirements  themselves  change  in  response  to  changing  external  needs 
The  result  is  scope  growth    Such  growth  has  a  negative  dynamic  impact:  reinforcing  work  to  be  done  and  often 
dominating  the  balancing  effects  of  iteration  Consider  a  study  of  scope  change  impacts  conducted  by  the 
Construction  Industry  Institute.83  The  study  examined  the  change  in  productivity  resulting  from  increasing  fractions 
of  change.  The  study  compiled  data  for  104  projects  from  35  different  companies.  The  results  showed  that 
engineering  productivity  (measured  as  a  ratio  of  earned  work-hours  to  expended  work-hours)  decreased  linearly  at  a 
rate  of  5%  productivity  for  10%  increase  in  design  changes   The  effect  translated  into  similar  productivity  decreases 
for  construction. 

3.2       Acquisition  Process. . .  Points  of  View 

To  facilitate  the  management  of  the  above  systems  engineering  approach,  the  Department  of  Defense  has 
formalized  the  stages  and  processes.  The  formal  process  is  referred  to  as  the  acquisition  process.  Figure  18  shows 
the  major  phases  and  milestones  of  the  acquisition  process.  The  acquisition  process  includes  many  steps  that  extend 
both  before  and  following  systems  engineering.  For  instance,  pre-Milestone  0  includes  not  only  requirement 
definition  (Determination  of  Mission  Need)  but  also  the  examination  of  available  technologies  (Science  and 
Technology)  that  would  be  required  to  support  Functional  Analysis  (Concept  Exploration  )  The  examination  of 


81  Abdel-Hamid  &  Madniclc  Software  Project  Dynamics:  an  Integrated  Approach.  Prentice  Hall.  New  Jersey,  page 
95-96 

8:  Ibid,  page  101. 

83  Construction  Industry  Institute,  "Quantitative  Effects  of  Project  Change ".  CII  Source  Document,  March  1990. 
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technologies  may  itself  be  a  systems  engineering  exercise  as  managed  research  solutions  must  be  constantly 
assessed  for  the  range  of  applications  to  which  those  technologies  are  being  developed.  The  acquisition  process  also 
extends  beyond  production  level  engineering  at  Phase  II  (Engineering  &  Manufacturing  Development.) 
Specifically,  the  acquisition  process  manages  the  complete  production  (Phase  III)  and  support  (Operational  Support 
and  Demilitarization  &  Disposal)  for  the  fielded  system.  As  such,  the  acquisition  process  encompasses  not  only 
system  development,  but  the  entire  life  cycle  of  the  system 
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Figure  18  Acquisition  Milestones  and  Phases84 

Perhaps  the  largest  difficulty  in  understanding  the  naval  ship  design  process  (or  any  defense  design  process) 
is  the  large  field  of  views  that  process  observers  may  take.  Consider  Figure  19  below.  This  diagram  shows  the 
range  of  management  considerations  (shown  as  timelines)  contained  within  the  DD-2 1  acquisition  process.  Within 
this  program,  participants  may  take  widely  differing  process  views  based  on  their  own  requirements  to  focus  or 
optimize  process  efforts  relative  to  a  particular  trade-off.  For  instance,  the  primary  engineering  focus  is  the 
sequence  of  design  reviews  (ASR  through  FCA)  necessary  to  define  conceptual  baselines,  system  definition  and 
design  producibility.  The  engineering  view  seeks  to  provide  the  best  physical  system  (performance)  as  a  response  to 
the  given  requirements.  Alternatively,  budgetary  and  fiscal  managers  are  focused  on  milestone  relationships,  since 
the  satisfaction  of  specific  milestones  translate  directly  into  funding  increases  required  to  support  continuing  levels 
of  design  effort.  Additionally,  budgetary  managers  optimize  the  use  of  funds  against  budgetary  and  fiscal  risk. 
Industry  and  acquisition  managers  must  concentrate  on  the  various  contracting  phases  (in  addition  to  the  other 
process  phases)  in  order  to  maximize  allocation  of  intermediate  program  funds  (such  as  support  contracts)  while 
remaining  poised  to  compete  for  the  final  contract  award.  Additionally,  industry  managers  seek  to  optimize 
producibility  relative  to  their  own  production  processes.  Through  optimization  of  cost  and  schedule,  industry  seeks 
to  gain  a  competitive  advantage  for  contract  award. 

Each  of  these  points  of  view  are  seeking  to  develop  a  systems  level  optimization  of  the  final  design 
However,  the  optimization  is  relative  to  the  area  of  concern  to  the  particular  component  managers.  This  is  not  to  say 
that  component  managers  ignore  total  system  optimization    They  are  quite  aware  of  the  potential  impacts  resulting 
from  changes  to  a  particular  system  element.  They  are  especially  sensitive  to  the  impacts  of  changing  inputs 


84  Defense  Acquisition  Deskbook  Joint  Program  Office,  "Defense  Acquisition  Deskbook,  Version  2.2.87".  Wright- 
Patterson  Airforce  Base.  Dayton.  OH.  December  15,  1997. 
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resulting  from  system  interdependencies.  Ever  changing  requirements  of  the  military  and  resulting  changes  in 
optimization  priorities  dictate  that  no  one  element  dominates  through  the  entire  design  process.  As  such,  component 
managers  must  constantly  strive  to  champion  their  system  element  to  achieve  necessary  consideration  in  the  final 
design.  The  dynamic  impacts  of  these  changes  have  already  been  demonstrated  (see  discussions  of  Table  2  and 
Figure  16).  These  competing  relationships  and  task  interdependencies  are  examined  in  detail  in  Chapter  4.  The 
immediate  results  of  compartmentalized  and  competing  demands  are  obvious:  each  component  manager  pushes 
forward  with  necessary  tasking  despite  changing  priorities  and  no  one  component  view  delivers  total  system 
optimization. 

In  this  environment  of  competing  system  interests,  it  is  the  task  of  the  program  manager  to  assess  the  needs  of 
the  developing  system,  determine  the  range  of  available  resources,  and  assign  priorities  to  optimization  goals 
Within  this  context,  the  program  manager  works  to  the  following  principles  and  objectives:85 

•  Ensure  effective  design  and  price  competition. 

•  Improve  system  readiness  and  sustainability 

•  Increase  program  stability  through  effective  long-range  planning,  use  of  evolutionary  alternatives, 
realistic  budgeting  and  funding  of  programs  for  the  total  life  cycle,  and  planning  to  achieve  economical 
production  rates 

•  Delegate  authority  to  the  lowest  levels  of  the  service  that  can  provide  a  comprehensive  review  of  the 
program. 

•  Achieve  a  cost-effective  balance  between  acquisition  costs,  ownership  costs,  and  system  effectiveness  in 
terms  of  the  missions  to  be  performed. 

Given  this  range  of  responsibilities  and  management  decisions,  the  program  managers  tasking  in  the  design  process 
naturally  extends  to  all  facets  of  the  project.  This  fact  is  explored  more  fully  in  Chapter  4.4. 


ss  Kockler,  Withers.  Poodiack  and  Gierman.  Systems  Engineering  Management  Guide.  Defense  Systems 
Management  College.  January  1990,  page  2-1. 
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3.3       Operational  Process  View 
3.3.1      Design  Phases 

Increasingly,  naval  ship  design  is  becoming  a  subset  of  total  ship  systems  engineering  (TSSE).  Ship  concept 
exploration  and  combat  system  development  must  begin  well  in  advance  of  the  actual  ship  design  process.  As  such, 
the  superset  of  system  design  spaces  will  encompass  many  layers  of  system  optimization  and  process  views.  The 
global  externalities  described  in  chapter  2  represent  a  strategic  view  of  the  design  process.  The  system  design  and 
acquisition  processes  described  in  sections  3. 1  and  3.2  represent  macro  views  of  the  design  process.  The  remaining 
views  are  operational  views.    The  operational  views  provide  the  exacting  structure  that  is  necessary  to  capture  the 
dynamics  of  design  process  change  relative  to  process  improvements.  Specifically,  the  operational  views  are 
represented  by  the  notions  of  Design  Phases  and  the  Design  Spiral.  The  design  spiral  is  examined  in  detail  in 
chapter  4.  This  section  examines  the  four  phases  of  naval  ship  design:  Concept  Design,  Preliminary  Design. 
Contract  Design  and  Detail  Design. 

Concept  Design  is  the  phase  during  which  the  solution  space  is  examined  to  identify  potential  cost-effective 
solutions  to  the  stated  requirements.  In  the  acquisition  process,  this  stage  is  represented  by  all  activities  prior  to 
Milestone  I.  The  requirements  are  presented  by  the  ongoing  Requirements  Definition  subphase  during  which 
warfighters  recognize  an  operational  need  and  translate  that  need  into  requirements  for  engineering  and  acquisition. 
The  overall  ship  system  is  emphasized  with  specification  of  components  limited  to  a  few  significant  system  drivers, 
such  as  weapons  or  propulsion  plants.  The  products  of  the  Concept  Design  are  a  set  of  defined  requirements  and  a 
design  space  of  achiev  able  solutions  to  requirements. 

Note  that  the  iterative  properties  of  the  macro  view  of  systems  engineering  are  present  both  externally  and 
internally.  Externally,  the  concept  design  phase  represents  the  first  stages  (requirements  and  functional  analysis)  of 
systems  engineering.  Internally,  concept  design  contains  explicit  elements  of  all  system  engineering 
steps  . .  requirements,  synthesis,  approval  and  description  of  system  elements  for  the  next  phase.  These  internal  and 
external  characteristics  are  common  to  all  design  phases. 

Preliminary  Design  is  that  phase  during  which  one  or  a  few  desired  concepts  are  refined  by  analysis  and 
integration  of  specified  components  to  confirm  acceptable  system  capabilities,  hi  the  acquisition  process, 
preliminary  design  is  represented  by  Phase  II  (or  more  often  Phase  II A.)  The  purpose  of  preliminary  design  is  to 
focus  on  overall  system  effectiveness  and  assurance  that  specified  systems  can  be  technically  and  economically 
supported  by  the  ship  design.  In  particular,  engineers  and  managers  concentrate  on  high  risk  elements  of  the  design. 
Such  high  risk  elements  may  include:  industrial  base  support,  combat  systems  integration,  hullform  performance 
characteristics,  life  cycle  cost,  or  optimization  of  marine  systems  efficiency.  As  a  result  of  in  depth  analysis  of 
specific  systems,  the  products  of  preliminary'  design  contain  increasing  degrees  of  component  specification,  but  still 
focus  primarily  on  system  level  definitions. 

Contract  Design  is  the  specification  of  design  attributes  necessary  to  reduce  risk  for  the  Navy  during  the 
award  and  constniction  of  the  selected  design   The  contract  design  process  is  still  functionally  oriented.  However. 
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increasing  numbers  of  components  are  specified  in  detail.  Specifically,  design  attributes  are  specified  by  contract 
specifications  to  constrain  design  performance  and  reduce  risk.  These  constraints  may  in  turn  constrain  costs, 
possibly  to  the  detriment  of  the  design  process.  Like  preliminary  design,  contract  design  is  part  of  phase  II  of  the 
acquisition  process  (or  phase  IIB). 

It  is  important  to  note  that  the  traditional  design  responsibility  up  to  and  including  contract  design  has  resided 
with  the  Navy.  As  discussed  in  Chapter  1.1.1.  NAVSEA  would  conduct  the  bulk  of  engineering  analysis  with 
contractors  providing  support  services,  but  providing  little  influence  over  the  direction  of  the  design.  However,  this 
trend  is  changing.  Recall  the  transition  points  shown  in  Figure  5.  Under  the  old  (DDG-5 1  and  prior)  approaches  to 
surface  combatant  design,  the  end  of  contract  design  represented  the  transition  point  of  the  design  from  the 
government  to  the  shipbuilder.  Under  this  approach,  the  shipbuilder  received  very  specific  contract  and  military 
specifications  directing  the  materials,  components,  and  even  production  methods  for  the  design.  As  shown 
previously,  the  result  of  this  inflexibility  was  delays  due  to  late  GFI/GFE/GFM.  schedule  and  cost  growth  in  excess 
of  marginal  scope  changes,  and  increasing  ship  production  costs.  To  counter  these  effects,  current  programs  (DD- 
2 1)  are  pursuing  earlier  transition  of  design  responsibility.  By  specifying  performance  requirements,  shipbuilders 
are  free  to  pursue  design  alternatives  optimized  to  their  production  capabilities.  Although  the  contractors  will 
assume  early  design  responsibility,  there  must  still  be  a  detailed  contract  specification  prior  to  shipbuilding  contract 
award.  This  contract  specification  is  necessary-  to  define  the  product  for  which  ship  construction  funds  (SCN)  are 
allocated  as  well  as  commit  the  shipbuilder  to  legally  binding  design  performance  (i.e.  a  performance  specification 
will  not  hold  the  weight  of  a  contract  specification  in  a  court  of  law.) 

Detail  Design  is  the  phase  during  which  system  descriptions  are  translated  into  the  instructions  required  to 
support  construction,  operation  and  support  of  a  finished  ship.  Within  Detailed  Design  are  four  sub-phases  required 
to  support  contractual  and  production  requirements.  During  Functional  Design,  the  shipbuilder  specifies  ship 
system  components  and  verifies  that  the  selected  systems  will  satisfy  performance  requirements.  Functional  Design 
provides  the  linkage  between  desired  system  configuration  and  specified  performance  predicted  by  contract  design 
and  realized  system  performance  available  from  a  producible  design.  Functional  Design  is  sometimes  associated 
with  contract  design  by  the  notion  of  Contract  Definitization.  This  is  potentially  significant  when  multiple  lead 
ship  contractors  are  bidding  for  a  project.  During  such  instances,  functional  design  represents  a  further 
demonstration  of  design  quality  and  cost  for  differentiation  of  contract  bids.  However,  experience  has  shown  that 
lead  ship  design  awards  typically  proceed  in  advance  of  contract  design  end.  As  such,  functional  design  becomes 
the  imtiation  of  detailed  design  concurrent  with  completion  of  contract  design.  Transitional  Design  takes  the  ship 
system  description  and  incorporates  it  into  a  process-based  description.  Long  lead  items  (propulsion  engines, 
propellers,  combat  system  components,  etc)  and  material  requirements  lists  (MRL's)  are  incorporated  into  the 
shipbuilder  logistics  system.  Zonal  Design  develops  components  into  drawings  consistent  with  the  work 
breakdown  structure  required  for  ship  construction.  After  this  subphase.  the  Navy  will  own  and  within  contractual 
limits,  distribute  the  design  to  all  ship  builders  who  have  successfully  bid  for  a  construction  contract.  For  tins 
reason,  these  first  three  sub-phases  of  detailed  design  (Functional.  Transitional  and  Zonal  Design)  are  often  referred 
to  as  Lead  Ship  Design.  For  a  lead  ship  design  effort,  the  products  are  intended  to  support  all  ship  builders  and 
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component  vendors  participating  in  the  ship  construction  program.  However,  the  actual  process  will  often  result  in 
detailed  design  attributes  that  support  the  construction  of  the  ship  in  the  Lead  Ship  Yard  As  such,  participating 
yards  will  necessarily  modify  the  Lead  Ship  Design  to  be  compatible  with  their  production  processes.  The  result  is 
the  very  notable  difference  between  ships  of  a  common  class  built  m  competing  ship  yards.  The  final  stage  of 
design.  Production  Design  or  Manufacturing  Engineering,  begins  as  soon  as  engineering  and  production 
resources,  as  well  as  zonal  design  products,  permit  initiation.  Production  Design  extracts  the  final  drawings  (lofting) 
and  manufacturing  instructions  required  to  produce  the  ship.  This  phase  also  provides  the  interface  with  the 
construction  site  to  resolve  design  conflicts  encountered  during  construction. 

3.3.2      Scope  Change  Implementation  and  Detailed  Design 

Detailed  Design  is  influenced  by  dynamics  encountered  due  to  "Internal  Change"  (producibility 
accommodations,  error  and  interference)  and  "External  Change"  (engineering  change  proposals  and  GFI/VFI 
changes).87  Internal  Change  represents  those  factors  over  which  the  design  organization  has  some  degree  of  control. 
Internal  changes  include  Engineering  Assistance  Requests  (EARs)  or  producibility  enhancements.  The  dynamics  of 
internal  changes  require  assessment  of  the  improvement  versus  detrimental  impacts.  For  instance,  error  rates  can  be 
reduced  with  increased  QA.  However,  increased  QA  naturally  delays  the  schedule  and  commits  valuable  resources 
away  from  tasking.  Thus,  a  trade-off  must  be  determined  internal  to  the  project.  External  Changes  are  those  factors 
over  which  the  organization  has  little  control.  External  changes  are  either  Navy  Engineering  Change  Proposals 
(ECPs)  or  vendor  changes.  For  instance,  as  requirements  change,  the  design  must  change  (despite  the  negative 
system  impacts  of  change)  otherwise  the  design  fails  to  meet  the  perceived  need. 

All  changes  are  analyzed  for  schedule,  material  and  production  impact.  The  level  of  analysis  varies 
depending  on  the  complexity  of  the  change.  A  simple  interference  identified  by  an  EAR  will  be  analyzed  by  the 
production  design  representative  on  the  waterfront  and  processed  in  accordance  with  standard  procedures.  A 
complex  ECP  is  analyzed  by  system  and  functional  engineering,  design,  material  engineering  and  planning 
specialists.  If  the  proposed  change  is  considered  necessary,  an  action  plan  is  developed  which  integrates  the  change 
into  design  and  construction  process. 

Design  changes  originating  during  the  construction  process  are  provided  to  manufacturing  as  interim  products 
known  as  "Revision  Notices"  (RNs).  Through  a  "lock-step"  process,  fabrication  and  installation  drawings  extracted 
from  the  CAD  models  are  continually  maintained  to  reflect  the  current  design  baseline  via  RNs.  It  is  essential  that 
configuration  control  of  the  models  and  drawings  be  maintained  while  new  design  changes  are  introduced.  Revised 
drawings  are  reproduced  at  regular  intervals  to  support  the  next  follow  on  hull  that  take  into  account  the  multiple 
design  changes  created  during  the  construction  of  the  previous  hull.  During  these  maintenance  cycles,  all 
outstanding  change  paper  is  accounted  for  and  a  "clean  drawing"  is  produced.  Similar  to  the  lock-step  process,  parts 
lists  are  continually  updated  as  changes  are  identified.  External  Change  and  Internal  Change  are  specific 
representations  of  scope  growth  of  a  project. 


87  C.  R.  Lloyd.  "Design  Process  for  the  AEGIS  Destroyer  Program".  Presentation.  Bath  Iron  Works  D87  Class 
Design  Office.  November  18,  1997,  page  6. 
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4       Design  Spiral  and  Task  Dynamics 

4.1       "The  Design  Spiral" 

The  design  of  a  ship  is  not  the  act  of  designing  specific  equipment. .  rather;  it  is  the  integration  of  systems  and 
equipment  to  optimize  cost  and  effectiveness.88  Such  activity  is  inherently  multi-disciplinary  ("no  single  person  can 
be  expert  in  all  these  areas"89)  and  highly  iterative.  However,  this  is  not  to  say  that  the  process  is  without 
recognizable  structure  and  organization.  To  the  contrary,  the  naval  ship  design  process  must  follow  very  specific 
steps  and  satisfy  fundamental  physical  laws  in  order  to  achieve  a  balanced  design.  These  balanced  properties  range 
from  the  most  basic  (hydrostatic  balance,  resistance-to-powering  balance,  structural  stress-to-integrity  balance,  etc) 
to  those  demanded  for  increased  effectiveness  and  decreased  cost  (passive-vs.  active-defense  trade-offs  and  design 
optimization  vs.  producible  design.) 

The  most  widely  accepted  methodology  used  to  balance  design  requirements  to  ship  components  is  the  design 
spiral.  The  design  spiral  describes  the  process  that  compartmentalizes  the  design  disciplines  and  regiments  the 
engineering  steps  necessary  for  a  balanced  design.  Figure  20.  shows  a  typical  example  of  such  a  spiral.  (Note  that 
the  concept  of  the  design  spiral  is  attributed  to  Professor  J.H.  Evans  of  MIT  and  was  first  introduced  in  the  Naval 
Engineers  Journal,  November  1959.) 

Fundamentally,  the  spiral  is  a  ship-system  algorithm  that  combines  physical  relationships  with  trade-off 
options.  The  spiral  is  characterized  by  a  sequence  of  specific  tasks  that  incorporate  initial  design  requirements, 
synthesize  these  requirements  into  a  set  of  design  characteristics,  assess  the  design  characteristics  against  the 
requirements  and  against  one  another,  and  iterate  as  necessary  to  achieve  convergence  of  the  values.  The  design 
spiral  relies  on  three  important  features  to  enable  analysis  and  convergence.  First,  the  design  space  from  which  all 
potential  design  characteristics  may  be  chosen  is  not  infinite.  Rather,  the  design  translate  into  a  specific  design 
space  (known  as  design  lanes.)  These  design  lanes  enable  engineers  to  assume  a  set  of  initial  ship  characteristics 
and.  thus,  proceed  with  the  design  analysis.  Secondly,  the  spiral  generates  specific  design  characteristics  and 
modifies  the  values  as  necessary  to  meet  requirements.  As  such,  the  design  assumptions  at  the  beginning  of  a  spiral 
differs  somewhat  from  those  at  the  end  of  an  iteration.  The  spiral  process  incorporates  the  new  design  values  into 
each  successive  iteration  until  the  values  converge  to  a  balanced  design.  Design  balance  indicates  the  defined  ship 
characteristics  are  physically  stable  while  satisfying  design  requirements.  It  is  important  to  note  that  a  balanced 
design  may  not  necessarily  represent  the  optimal  design.9"  Finally,  as  iterations  proceed  and  convergence  is 
achieved,  the  process  of  synthesis  and  analysis  seeks  greater  and  greater  levels  of  detail.  For  instance,  imtial 
structural  analysis  incorporates  simple  beam  theory,  ship  section  modulus  and  accepted  design  practices.  Later 


Gale  and  Scott,  "Early  Stage  Ship  Design  Seminar",  The  Society  of  Naval  Architects  and  Marine  Engineers, 
October  1995. 

89  Tibbitts  and  Keane.  "Making  Design  Everybody's  Job",  Naval  Engineers  Journal.  May  1995,  page286. 

90  Allan  Andrew,  "Multi-Attribute  Decision  Making  Analysis  with  Evolutionary  Programming  Applied  to  Large 
Scale  Vehicle  II",  Thesis  for  Ocean  Engineering,  Massachusetts  Institute  of  Technology'.  Cambridge.  MA,  May 
1998. 
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iterations  incorporate  greater  design  detail  such  as  finite  element  analysis  for  both  static  and  dynamic  loads.  Finally, 
the  design  incorporates  structural  arrangement  details  necessary  for  construction.  Each  increase  in  detail  requires 
comparison  of  design  characteristics  for  convergence.  The  result  is  a  convergent,  producible  design  and  greater 
confidence  with  respect  to  design  requirement  nsk. 
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Figure  20  Generic  Ship  Design  Spiral 

There  is  no  one  spiral  that  is  correct  for  all  ship  designs.  A  proposed  spiral  must  incorporate  design  and 
analysis  elements  necessary  to  satisfy  requirements.  Tn  particular,  the  spiral  task  elements  may  vary  by  mission 
requirements,  level  of  risk  mitigation  required  or  level  of  sub-system  and  total  system  maturity.  For  those  general 
design  disciplines  that  are  chosen  for  a  given  spiral,  sub-spirals  may  be  necessary  within  a  design  node  in  order  to 
generate  and  analyze  specific  design  characteristics.  For  example,  it  is  necessary  to  balance  auxiliary  system 
capacity  to  electrical  power  generation  to  payload  support  requirements  within  the  marine  engineering  discipline. 
The  consequence  of  layers  of  design  and  analysis  is  a  set  of  nested  iterations  of  design  within  the  overall  design 
structure.    Figure  2 1  shows  an  example  of  this  concept.  Additionally,  the  view  of  the  spiral  may  change  to 
accommodate  varying  process  interpretations:  viewed  as  either  moving  from  the  outer  rings  inward  or  from  the 
center  outward.  If  outer  to  inward,  the  view  is  one  of  considering  the  initial  development  of  numerous  conceptual 
designs  with  each  narrowing  ring  focusing  the  effort  to  fewer  and  fewer  design  options  and  culminating  in  a  single 
final  design.  Alternately,  the  view  of  increasing  arc  lengths  from  center  to  outward  represents  the  increasing  detail 
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required  of  each  iteration  to  validate  the  final  design.91  Whatever  the  view  or  structure,  the  spiral  provides  a  common 
baseline  to  begin  discussion  of  design  process  and  disciplines  necessary  to  develop  and  evaluate  the  design. 
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Figure  21  Nested  Design  Iterations 

These  views  of  the  design  process  are  consistent  with  the  basic  structure  for  project  models  utilized  in  system 
dynamics.  Namely,  the  iterative  nature  reflects  a  necessity  to  take  a  set  of  initial  (or  baseline)  tasks  to  be  done, 
perform  those  tasks  to  a  level  of  productivity,  and  rework  the  tasks  due  to  varying  levels  of  design  quality.  Figure 
22  shows  an  example  of  the  system  dynamics  model  structure.  For  naval  ship  design,  the  system  dynamics  variable 
''initial  work  to  be  done"  is  equivalent  to  the  number  of  design  nodes  within  the  design  spiral.  Productivity  is  the 
rate  of  design  accomplishment  consistent  with  the  number  of  designers  assigned  to  and  the  complexity  of  the  task. 
Quality  may  be  interpreted  as  the  rate  of  design  convergence  (i.e.  the  quantity  of  tasks  requiring  re-iteration.) 
Undiscovered  rework  and  rework  discovery  represent  the  analysis  steps  of  the  design  spiral.  Known  rework  and 
rework  accomplishment  represent  subsequent  iterations  of  the  spiral. 

For  typical  project  management  models,  this  system  dynamics  structure  is  the  basic  "engine"  for  process 
flow    The  base  structure  is  then  adjusted  systemically  to  account  for  the  impacts  of  various  project  management 
policies.  For  example,  manpower  allocation,  budget,  scope  changes,  project  schedule,  overtime  and  others  may 
introduce  feedback  effects  on  productivity,  quality,  and  work  to  do.  These  structures  are  explored  more  fully  in 
Chapter  5,  Process  Model  Sectors. 

As  a  basic  system  dynamics  structure  (or  molecule92),  it  is  possible  to  begin  using  this  structure  to  analvze  the 
naval  ship  design  process.  However,  the  design  spiral,  as  presented  above,  does  not  completely  capture  the  design 
process.  It  is  necessary  to  understand  that  the  spiral  interpretation  does  not  fully  reflect  the  method  of  design  used 


by  engineers 


93 


91  David  Brown,  "Naval  Architecture",  Naval  Engineers  Journal.  January  1993.  pages  43-44. 

92  Jim  Hines,  ''Molecules",  a  presentation  to  MIT-Sloan  course  Application  of  System  Dynamics,  Cambridge.  MA 
Spring.  1998. 

3  Tan  and  Bligh,  "A  New  Approach  to  an  Integrated  CAD  Method  for  Surface  Ship  Design",  Naval  Engineers 


Journal.  January  1998.  page  36-37. 
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Figure  22  Generic  System  Dynamics  Project  Structure 

Consider  a  sampling  of  tasks  for  a  typical  ship  design  (Table  9  and  Figure  23.)  The  listed  tasks 
(arrangements,  structural  analysis,  propulsion . . . )  represent  specific  points  on  the  design  spiral.  Note  that  the 
number  of  issues  for  each  task  element  are  not  the  same.  Each  iteration  of  the  design  spiral  is  not  equivalent  with 
respect  to  the  tasks  to  be  done.  Additionally,  the  time  duration  of  each  issue  that  is  performed  during  a  design 
iteration  is  non-linear  (note  the  numerous  slope  changes  in  both  iteration  duration  and  periods  between  tasks.)  This 
indicates  the  order  of  tasks  within  the  spiral  is  changing.  The  design  spiral  is  not  linear. 


Task 

Preliminary  Design 

Contract  Design 

General  Arrangements 

1250  Hours 

3250  Hours 

-  General  Arrangements  Drawings 

3  Issues 

4  Issues 

-  Area/Volume  Report 

3  Issues 

4  Issues 

-  Personnel  Access  Study 

1  Issue 

1  Update  Issue 

Structures 

780  Hours 

2140  Hours 

-  Midship  Section 

2  Issues 

3  Issues 

-  Shell  Expansion 

1  Issue 

3  Issues 

-  Calculation  Report 

1  Issue 

2  Issues 

Propulsion 

1500  Hours 

3520  Hours 

-  Machinery  Arrangement  Drawings 

2  Issues 

4  Issues 

-  Endurance  Fuel  Calculations 

2  Issues 

3  Issues 

Etc... 

Etc. 

Etc... 

Table  9  Sample  Task  Estimates  for  an  Auxiliary  Ship 


94  James  Lyneis.  "Calibration  of  System  Dynamic  Models",  a  presentation  to  MIT-Sloan  course  Application  of 
System  Dynamics,  Cambridge,  MA.  April  17,  1998. 
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Figure  23  Sample  Design  Schedule  Estimates  for  an  Auxiliary  Ship96 

This  is  a  fundamental  shortfall  m  the  spiral  concept.  The  spiral  portrays  the  design  process  as  linear.  This  is 
not  the  case.  The  process  is  better  described  as  "quasi-linear."  The  progression  of  tasks  normally  proceeds  in  a 
controlled,  sequential  manner.  However,  all  design  tasks  within  the  spiral  rely  on  input  from  and  provide  output  to 
almost  every  other  node  of  the  process    As  such,  engineers  and  designers  must  have  access  to  information  (whether 
actual  or  estimated)  from  each  design  discipline  and  they  must  be  acutely  aware  of  the  potential  feedback  effects 
caused  by  the  changing  output  from  their  own  design  products.  As  a  result  of  these  interrelationships,  the  spiral  is 
actually  a  network  or  "interaction  mesh"  joining  design  nodes  by  physical  relationships  and  information  flows. 

Take  a  simple  example:  power  balance  (Figure  24).  Suppose  the  current  iteration  of  a  ship  design  does  not 
achieve  desired  speed.  The  current  hullform  results  m  required  horsepower  for  speed. ..  approximately  a  cubic 
relationship.  The  required  horsepower  corresponds  to  a  larger  propulsion  plant  concept.  ..a  non-continuous  step 
function.  The  propulsion  plant  requires  a  larger  machinery  volume  and  larger  displacement . . .  propulsion  plant 
power  density  increases  asymptotically.  The  hullform  grows  to  accommodate  larger  propulsion  stack 
length ...  volume  growing  as  the  cube  of  linear  dimensional  increases  in  plant  size.  Support  systems  also  grow  with 
the  larger  propulsion  system  and  larger  hullform. . .  system  weights  increasing  with  hull  parameters  and  propulsion 
plant  horsepower.  The  larger  hullform  results  in  greater  hull  weight. .  hull  weight  increases  as  L~-L3  and  hull 


5  Ron  Nix.  "T-AG9X  Preliminary/Contract  Design  Estimates",  Naval  Sea  Systems  Command.  January  16.  1987. 
16  Ibid. 

''  David  Brown,  "Naval  Architecture",  Naval  Engineers  Journal.  Januarv  1993.  pages  44-45. 
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surface  area  increases  as  L2.  The  new  hullform  and  displacement  result  in  an  increase  in  horsepower  required  for 
powering  at  the  desired  speed,  .hull  resistance  increasing  in  frictional  resistance  with  increased  displacement  and 
varying  in  wave  and  residual  resistance  by  the  choice  of  hull  parameters.  The  result:  increasing  power  to  achieve 
speed  can  result  in  a  need  to  further  increase  power  to  achieve  speed.  The  key  to  convergence  of  tliis  process  will 
depend  on  the  relationship  of  the  various  non-linear  parameters  and  the  choices  of  designers  to  manage  feedback  of 
those  parameters.  Also,  note  that  the  design  process  is  impacted  by  many  of  the  disciplines  of  the  spiral  (marine 
engineering,  hydrodynamics,  structural  engineering,  weight  engineering,  etc  )  and  did  so  in  a  non-linear  sequence. 
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Figure  24  Simple  Iterative  Design  Network 

Another  example  of  the  design  process  as  '"quasi-linear"  spiral  is  seen  in  the  application  of  design  synthesis 
software.  The  Advanced  Surface  Ship  Evaluation  Tool  (ASSET)  is  a  concept  and  preliminary  design  synthesis  tool 
used  by  the  United  Suite  Navy  to  balance  and  assess  various  naval  ship  concepts.  The  program  is  structured  as 
presented  in  Figure  25.  The  figure  shows  how.  like  the  spiral.  ASSET  proceeds  sequentially  through  a  series  of 
design  tasks  (called  modules)  and  iterates  solutions  for  a  convergent  design   This  progression  leads  to  a  linear  view 
of  the  design  process.  Figure  25  also  shows  a  sample  of  the  master  parameter  list  (MPL.)  The  MPL  is  a  product 
model  database  containing  all  design  attributes  used  as  input  and  generated  as  output  by  the  ASSET  modules.  It  is 
the  interaction  of  the  sequential  modules  with  the  MPL  that  creates  dynamic,  non-linear  design  behavior  similar  to 
that  seen  in  Figure  24. 

To  demonstrate  this  behavior,  consider  the  analysis  of  the  DDG-51  in  ASSET.  The  baseline  ship  has  four  GE 
LM-2500  gas  turbines  propulsion  engines  with  19220.4  kW  each.  This  results  in  a  total  shaft  power  of  74.974  kW 
and  a  resultant  maximum  speed  of  3 1 . 2  kts.  Suppose  that  a  step  decrease  of  propulsion  power  is  proposed  by 
replacing  the  current  LM-2500  model  30  engines  with  smaller  model  21  engines.  The  smaller  engines  provide 
16032.5  kW  each.  62,539  kW  total  shaft  power  and  a  maximum  speed  of  30.2  kts.  The  synthesis  of  this  change 
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requires  5  iterations  of  the  design  in  ASSET.  During  each  iteration,  the  ASSET  modules  modify  ship  characteristics 
stored  in  the  MPL  and  consider  the  characteristics  non-convergent  if  the  values  change  by  more  than  0. 1%  from  the 
previous  iteration.  Table  10  lists  those  characteristics  for  each  non-convergent  iteration  that  posed  the  greatest 
differential  from  the  previous  iteration.  Note  that  the  appendage  module  converges  faster  then  the  others.  Also,  the 
auxiliary  and  weight  modules  are  each  limited  by  the  same  variable:  lightship  weight.  The  resistance  module  is 
most  limited  by  effective  horsepower  (EHP)  for  only  the  first  two  iterations  while  EHP  is  most  limiting  to  the 
machinery  array  for  all  iterations.  Generally,  the  iterations  demonstrate  a  variation  of  convergence  rates  among 
design  disciplines,  variations  of  limiting  characteristics,  and  the  coupling  of  design  variables  among  disciplines.  In 
other  words,  the  process  is  non-linear. 


Module 

Iteration  1 

Iteration  2 

Iteration  3 

Iteration  4 

HULL  GEOM 

GMT 

GMT 

GMT 

GMT 

HULL  SUBDIV 

HULL  ARR  AREA 
AVAIL 

SHAFT  ALLEY 
VOLUME 

SHAFT  ALLEY 
VOLUME 

SHAFT  ALLEY 
VOLUME 

DECKHOUSE 

AREA  BEAM 

AREA  BEAM 

AREA  BEAM 

AREA  BEAM 

HULL  STRUCT 

HOGGING  BM 

MIDSHIP  MOI 

SAGGING  BM 

SAGGING  BM 

APPENDAGE 

SKEG  PROJ 
AREA 

APPENDAGE 
DISP  ARRAY 

RESISTANCE 

SHIP  EHP 
ARRAY 

SHIP  EHP 
ARRAY 

PRPLN  SYS 
RESIST  ARRAY 

PRPLN  SYS 
RESIST  ARRAY 

PROPELLER 

PROP  RPM 
ARRAY 

PROP  RPM 
ARRAY 

PROP  RPM 
ARRAY 

PROP  RPM 
ARRAY 

MACHINERY 

SHIP  EHP 
ARRAY 

SHIP  EHP 
ARRAY 

SHIP  EHP 
ARPAY 

SHIP  EHP 
ARRAY 

AUXILIARY 

LIGHTSHIP  WT 
ARRAY 

LIGHTSHIP  WT 
ARRAY 

LIGHTSHIP  WT 
ARRAY 

LIGHTSHIP  WT 
ARRAY 

WEIGHT 

LIGHTSHIP  WT 
ARRAY 

LIGHTSHIP  WT 
ARRAY 

LIGHTSHIP  WT 
ARRAY 

LIGHTSHIP  WT 
ARRAY 

SPACE 

DKHS  ARR  AREA 
REQ 

OTHER  ARR 
AREA  REQ 

OTHER  ARR 
AREA  REQ 

OTHER  ARR 
AREA  REQ 

Table  10  Limiting  Characteristics  for  ASSET  Iterations  of  a  Propulsion  Change  to  DDG-51 

A  similar  non-linear  representation  of  design  synthesis  can  be  found  in  other  design  tools:  GODDESS 
(Government  Defense  Design  for  Ships  &  Submarines).  CONDES  (Concept  Design  Suite)  and  HFDS  (Hull  Form 
Definition  System.)98  Thus,  like  the  basic  design  spiral  described  previously,  seemingly  linear  structures  for  naval 
ship  design  synthesis  are  actually  non-linear  in  nature. 


Whatmore  and  Wintersteen,  A  Review  of  Extant  Design  Tool  Capabilities  to  Identify  Common  Design  Tool  for 
Future  Collaboration.  Naval  Surface  Warfare  Center  Carderock  Division,  Bethesda,  MD.  February  28.  1997. 
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Figure  25  ASSET  Program  Structure  and  Master  Parameter  List  Example 

In  order  to  properly  represent  the  naval  ship  design  process  in  a  system  dynamics  model,  there  must  be  an 
accounting  of  the  non-Linear  interactions  seen  in  the  design  spiral.  A  method  that  can  capture  this  behavior  is  the 
Design  Structure  Matrix  (DSM.)100  First  proposed  by  D.  V.  Steward  in  1981,  DSM  is  a  graphically  based  technique 
to  express  design  process  information  in  a  matrix  fonn.  The  matrix  stmcture  shows  design  tasks  by  input  and  output 
relationships.  These  relationships  can  be  found  from  physical  requirements  of  engineering  as  well  as  procedural 
requirements  and  structures  applied  by  design  managers. 

Consider  the  design  tasks  discussed  previously  (Table  9.)  The  tasks  demonstrate  a  combination  of  sequential 
and  concurrent  relationships.  These  relationships  can  be  captured  in  a  matrix.  A  possible  matnx  formulation  for  the 
tasks  is  shown  in  Figure  26.  The  rows  are  tasks  in  the  design  sequence  with  the  corresponding  columns  showing 
those  fields  that  provide  input  to  the  task  in  the  row.  The  diagonal  is  assumed  to  be  "0"  as  a  single  task  should  not 
be  dependent  on  itself  (note  that  this  assumption  may  not  be  correct  if  the  design  task  is  itself  a  compilation  of 
smaller  tasks.)  Each  matrix  element  is  represented  as  binary.  However,  it  is  possible  to  further  refine  the  "strength" 


J9  Naval  Surface  Warfare  Center  Carderock  Division.  "Getting  Started  &  Tutonals:  Advanced  Surface  Ship 
Evaluation  Tool  (ASSET)  Family  of  Ship  Design  Synthesis  Programs",  September  30,  1997.  page  3-29  and  page  3- 
22. 

100  Eppmger.  Whitney.  Smith  and  Gebala.  "A  Model-Based  Method  for  Organizing  Tasks  in  Product  Development". 
Working  Paper,  Massachusetts  Institute  of  Technology',  1993. 
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of  relationships  by  a  percentage  of  input  information  required,  differential  change  of  dependent  row  on  input  column 
or  other  order  of  magnitude  measure.101  Ideally,  the  sequence  of  rows  should  form  a  lower  triangle,  thus  showing 
that  tasks  proceed  sequentially  from  previous  tasks.  However,  the  non-hnear  relationships  of  the  naval  ship  design 
process  result  m  both  upper  and  lower  triangle  relationships. .  this  is  called  couple  development.  The  ability  to 
perform  effective  concurrent  engineering  (i.e.  maximize  productivity  and  minimize  rework)  is  dependent  on  the 
level  of  coupled  development,  the  strength  of  those  relationships,  and  the  ability  of  engineers  to  select  design  lanes 
(initial  design  assumptions)  that  minimize  iteration  differentials.  It  is  further  possible  to  optimize  a  process  by 
rearranging  task  sequences  to  minimize  the  upper  triangle  against  the  lower.  Such  optimization  is  particularly  useful 
for  reduction  of  design  code,  computational  effort  and  design  effort  in  synthesis  of  naval  ship  designs.102  Overall, 
DSM  combined  with  a  system  dynamics  model  provides  an  effective  means  to  represent  naval  ship  process 
dynamics. 


General  Arrangement  Drawings 
Area/Volume  Report 
Personnel  Access  Study 
Midship  Section 
Shell  Expansion 
Strength  Calculations 
Machinery  Arrangement  Drawings 
Endurance  Fuel  Calculations 


12  3  4  5  6  7  8 


1 

0  1    1 

0  0  0  11 

2 

1   0  0 

0  0  0  11 

3 

1    1   0 

0  0  0 

1   0 

4 

1   0  0 

0  1    1 

0  0 

5 

0  1   0 

1   0  1 

0  0 

6 

0  0  0 

1    1   0 

0  0 

7 

1    1   0 

0  0  0 

0  1 

8 

0  1   0 

0  0  0 

1  0 

Figure  26  DSM  for  Sample  Design  Tasks 


4.2       Design  Disciplines 


With  an  enhanced  understanding  of  the  design  spiral,  it  is  necessary  to  restructure  the  basic  system  dynamics 
project  management  structure  to  reflect  the  non-linear  process  seen  in  the  DSM  structure.  Additionally,  it  is 
necessary  to  structure  the  design  tasks  in  a  manner  that  appreciates  the  multitude  of  design  disciplines  applicable  to 
the  design  process  and  subsequent  task  accomplishment,  without  requiring  a  level  of  detail  that  precludes  effective 
understanding  and  exploration  (i.e.  minimize  the  DSM  structure.)  Specifically,  the  structure  must  reflect  the  variety 
of  design  tasks  within  a  single  phase,  the  inter-relationships  of  those  tasks,  and  the  growth  of  tasks  (as  a  function  of 
necessary  design  detail)  from  phase  to  phase. 

A  causal  loop  diagram  is  developed  to  understand  the  structure  that  must  be  included  in  a  naval  ship  design 
model.  Consider  the  following  situation: 

1 .     Initial  iteration  begins  with  a  quantity  of  design  tasks. 


101 


Ibid. 


Tan  and  Bligh.  "A  New  Approach  to  an  Integrated  CAD  Method  for  Surface  Ship  Design",  Naval  Engineers 
Journal.  January  1998,  page  35. 
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2.  Engineers  and  managers  with  specific  knowledge  of  their  design  disciplines  must  communicate 
information  related  to  their  design  tasking  to  the  group  in  order  to  provide  dependent  design  tasks  with 
input  data  (establishing  design  lanes), 

3 .  Based  on  the  level  of  organizational  communication  (ranging  from  disconnected  to  fully  integrated 
design  teams)  and  the  imposed  design  constraints  (such  as  design  requirements  and  design  margins),  an 
engineer  find  that  the  initial  assumptions  made  to  proceed  with  the  design  may  or  may  not  be  accurate  at 
the  end  of  the  design  iteration 

4.  As  a  result  of  interaction  .  if  communication  is  lacking  or  the  design  is  not  sufficiently  constrained  then 
the  design  tasks  may  be  delayed  due  to  competmg  variations  in  the  initial  design  assumptions  or  fail 
entirely  due  to  divergent  tasks  coupling. 

Figure  27  demonstrates  this  concept  graphically. 


Design  Task 
A  in  Progress 


Design  Task  I 
in  Progress 


Figure  27  Generic  Design  Task  Relationship 

The  rate  of  design  communication  and  thus,  the  rate  of  design  iterations  is  composed  of  both  controlled 
iterations  or  "baselme  freezes"  (those  designated  instances  in  the  design  process  during  which  all  design  elements 
are  frozen  to  a  common  set  of  values)  and  free  iterations  (those  communications  of  design  change  resulting  from  the 
direct  communication  of  engineers  or  exchange  of  design  characteristics  with  a  common  design  product  model.) 
"Baseline  freezes"  typically  occur  at  predictable  rates.  An  example  of  the  these  rates  are  shown  in  Table  11.  A 
baseline  freeze  represents  a  complete  design  spiral  and  thus,  a  complete  ship  design:  but  a  completed  spiral  may  not 
represent  a  fully  balanced  or  optimized  design.  Within  the  context  of  DSM,  a  baseline  freeze  would  be  a  complete 
sequencing  through  the  design  task  matrix.  Free  iterations  occur  due  to  coupled  development.  Designers  from  a 
dependent  task  group  communicate  at  some  rate  with  other  task  groups  and  update  information  to  maintain  accurate 
task  data.  A  slow  communication  rate  will  naturally  delay  the  design  process.  This  fact  has  been  noted  by  the 
method  of  "over  the  wall"  design.  However,  communication  at  too  quick  a  rate  could  be  equally  concerning. 
Specifically,  an  increased  rate  results  in  increased  communication  overhead  Increased  communication  may  result 
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in  decreased  time  for  productive  engineering  activities.  Additionally,  high  variations  in  input  data  can  result  in 
instabilities  in  convergence  rates.  Iteration  rates  and  communication  rates  impact  the  design  model. 


Design  Phase 

Typical  Number  Iterations 

Typical  Duration 

Concept  Design  Phase 

10-100 

3-5  days 

Preliminary  Design  Phase 

4-8 

3-6  weeks 

Contract  Design  Phase 

2-4 

1-3  months 

Detailed  Design  Phase 

1-2 

1-3  years 

Table  11  Typical  Design  Iteration  Issues  and  Durations103 

Based  on  this  behavior,  it  is  possible  to  model  the  cycle  time  relationship  of  task  accomplishment  with 
respect  to  design  interactions.  The  following  assumptions  apply  to  the  development  of  the  relationships: 

•  Only  first  order  relationships  are  modeled  (i.e.  hull  performance  is  a  function  of  hull  geometry,  but  only 
through  the  first  order  translation  of  hull  geometry  into  seakeeping  and  resistance  attributes) 

•  Relationships  are  considered  binary  (1  or  0)  regardless  of  the  degree  of  relationship.  However. 

•  Relationships  judged  as  existent  (1)  must  be  supported  by  direct  physical  properties  (i.e.  SWBS  Group 
100  Weight  is  a  direct  function  of  Hull  Geometry  parameters  and  Structural  dimensions)  or  legal  and 
management  requirements  (i.e.  all  aspects  of  the  design  process  must  provide  inputs  to  the 
programmatically  managed  design  history.)  See  Chapter  8.4  for  a  complete  list  of  references  used  to 
develop  relationships. 

4.3       Design  Task  Matrix 

Given  the  non-linearities  of  the  design  spiral  and  the  vast  quantity  of  design  tasks  accomplished  during  a 
naval  ship  design  (a  typical  surface  combatant  design  may  have  over  2,500  separate  ship  drawings  in  detail  design 
alone),  it  is  necessary  to  aggregate  the  tasks  into  appropriate  design  nodes.  Aggregation  allows  analysis  of  dynamic 
interactions  and  concurrency  relationships  relative  to  the  design  process,  while  maintaining  manageable  quantity  and 
quality  for  modeling.  An  analysis  of  design  products  (see  Chapter  8.4)  required  at  each  phase  of  design  (concept 
through  manufacturing)  and  for  each  system  discipline  shows  that  the  system  disciplines  can  be  grouped  into  6 
nodes  and  23  sub-nodes.  Table  12  shows  a  listing  of  the  nodes,  sub-nodes  and  a  designation  code  that  will  be  used 
throughout  the  remainder  of  this  work  and  the  design  model  to  refer  to  the  nodes. 


103 


Extrapolated  from  interviews  (see  Chapter  8.2)  and  basic  design  resources  (see  Chapter  8.4). 
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Designation 

Node 

Sub-Node 

AO 

Programmatic  Disciplines 

Al 

Program  Management  Tasks 

A2 

Requirements  &  Assessment  Tasks 

A3 

Risk  Mitigation  &  Coordination  Tasks 

BO 

Systems  Engineering 

Bl 

Logistics  &  Reliability  Engineering 

B2 

Design  Integration  &  Specifications 

B3 

Producibility  &  Production  Engineering 

B4 

Performance  &  Requirements  Engineering 

B5 

Manning 

CO 

Hull  Systems  Engineering 

CI 

Hull  Geometry 

C2 

Weight  &  Stability  Engineering 

C3 

Hydrodynamics-Resistance 

C4 

Hydrodynamics-Seakeeping 

C5 

Hydrodynamics-Maneuvering  &  Appendages 

C6 

Structural  Engineering 

CI 

Space  &  Arrangements 

DO 

Machinery  Systems  Engineenng 

Dl 

Machinery  Systems  Design  &  Integration 

D2 

Propulsion  Systems 

D3 

Electrical  Svstems 

D4 

Auxiliary  &  Support  Systems 

D5 

Deck.  Handling  &  Aircraft  Support  Systems 

EO 

Mission  Systems  Engineering 

El 

Mission  Systems  Selection,  Design  &  Integration 

E2 

Topside  Design  &  Integration 

FO 

Cost  Engineering 

Fl 

Cost  Estimation  &  Analysis 

Table  12  Design  Process  Nodes  and  Sub-Nodes 
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Analysis  of  the  relationships  of  these  task  elements  results  in  the  DSM  design  matrix  shown  (Figure  28.) 
Figure  29  shows  a  complete  network  resulting  from  the  matrix  relationships.  The  outer  ring  of  the  network 
represents  the  traditional,  linear  design  spiral.  The  interactions  represent  the  range  of  free  iterations  possible  in  the 
process.  Chapter  5  discusses  the  specific  approach  used  to  combine  the  system  dynamics  process  model  with  the 
DSM  model.  The  remainder  of  this  chapter  addresses  the  logic  supporting  the  DSM  elements  and  the  expected 
behavior  resulting  from  the  elements  and  nodes. 

Before  preceding,  note  that  the  following  assumptions  have  been  made  with  respect  to  the  DSM  structure: 

•  The  baseline  task  elements  (Table  14  through  Table  38)  are  specific  to  the  DDG-51  program.  As  such, 
elements  for  current  surface  combatant  design  programs  may  not  be  represented. 

•  The  discussions  associated  with  each  task  node  (Sections  4.4  through  4.9)  provides  a  justification  for  the  DSM 
relative  to  the  DDG-5 1  task  elements  as  well  as  highlighting  current  trends  in  tasks  and  interdependencies. 
Future  applications  of  the  DSM  structure  must  incorporate  dependency  shifts  resulting  from  those  trends. 


Figure  29  Design  Spiral  "Interactions" 

4.4       Programmatics 

Programmatics  represents  the  core  tasks  of  every  naval  ship  design  project.  It  may  also  be  referred  to  as 
Acquisition  Management.  Programmatics  contains  tasks  related  to  Program  Management,  Requirements  Setting  and 
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Assessment,  and  Risk  Mitigation  and  Coordination.  These  elements  support  the  creation  of  a  design  and  acquisition 
program,  management  of  the  design  and  contract  award  oversight  of  the  production  design  and  construction,  and 
engineering  support  to  the  operational  forces  throughout  the  life  cycle  of  the  ship.  Specific  programmatic  tasks  are 
required  by  DoD  Instruction  5000.2  (Defense  Acquisition  Management  Policies  and  Procedures)  and  DoD  Manual 
5000.2  M  (Defense  Acquisition  Management  Documentation  )    A  complete  listing  of  applicable  directives  is  found 
in  the  Defense  Acquisition  Deskbook  (http:* /www  dcskbook.osd.mil.)  Additionally,  tasks  are  necessitated  by  good 
engineering  and  business  practice  such  as  maintaining  a  design  history  or  managing  scope  growth. 

The  elements  of  programmatics  were  under  fire  in  recent  years  due  to  perceived  inefficiencies.  As  the 
fundamental  decision-making  support  systems,  programmatic  tasks  have  seen  a  natural  growth  in  project 
deliverables.  This  growth  correlates  to  increasing  technological  design  risk  and  pressure  to  decrease  design  cost  (see 
discussion  of  externalities  in  Chapter  2.)  The  result  is  increasing  time  required  to  prepare  documentation  (Table  13.) 
Figure  30  shows  task  efforts  (averages  for  45  Navy.  ACAT  I  design  programs)  expended  for  key  programmatic 
deliverables.  As  the  key  inputs  to  progn-m  milestones,  there  has  traditionally  been  a  need  to  produce  significant 
portions  of  these  documents  prior  to  each  review  stage,  which  may  include  as  many  as  ten  different  review  and 
approval  levels.104  The  combination  of  multiple  decision  layers  and  increasing  programmatic  efforts  is  viewed  as  a 
key  factor  contributing  to  the  growth  of  the  design  cycle. 


Ship  Program 

Preliminary  Design 

Contact  Design 

DDG-993 

N/A 

1,454 

CG-47 

1.818 

8.147 

DDG-51 

2,696 

23.654 

Table  13  Programmatic  Man-hour  Effort  Trends 


104 


William  Ball,  "DoD  Acquisition  Policy  and  the  Effect  on  Naval  Ship  Design",  Society  of  Naval  Architecture  and 
Marine  Engineering,  February  25,  1992,  page  7-5. 

105  Ship  Design  Group,  Ship  Design  Project  Histories:  Volume  I.  II  and  HI.  Naval  Sea  Systems  Command 
September  1978,  May  1986  and  August  1996. 
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Figure  30  Average  Programmatic  Documentation  Effort106 

To  counter  the^ :  trends,  significant  changes  were  implemented  with  respect  to  programmatics.  As  part  of 
acquisition  reform  initiatives  (see  Chapter  1.1.1),  contract  specifications,  programmatic  deliverables  and  design 
reviews  were  modified  to  remove  redundancies  and  outdated  requirements.  In  particular,  program  managers  are 
granted  greater  authority  to  reduce  documentation  requirements  and  waive  redundant  design  reviews  entirely.  These 
changes  have  significant  impacts  (positive  and  negative)  on  design  programs.  For  instance,  the  LPD-17  contract 
design  effort  was  negatively  impacted  when  a  directive  to  reduce  contract  specifications  was  implemented  well  into 
the  design  process.  Although  the  effort  reduced  contract  deliverables  (reduction  from  1.452  to  327  specifications), 
thus  improving  efficiency  in  lead  ship  design,  contract  design  efforts  were  delayed  several  months  to  implement  the 
reform  (the  effort  was  referred  to  as  ''triage".)107  Conversely,  reforms  allow  programs,  such  as  the  current  DD-21 
program,  to  realize  improved  management  efficiency  and  reduced  review  periods."'8  These  cases  indicate  that 
implementation  of  programmatic  reforms  may  dynamically  impact  a  project. 

In  order  to  simulate  programmatic  fluctuations  within  the  design  model,  the  following  assumptions  will  be 
made: 

1 .  Total  programmatic  requirements  (number  of  tasks  at  each  design  phase)  are  fixed  initially  for  the  model 

2.  A  capability  to  generate  random  and/or  specified  growth  and  decay  of  programmatic  tasking  is  included. 
Values  for  baseline  productivity  and  task  levels  are  provided  in  Chapter  8.5. 


RADM  Roger  B.  Home,  "Concept  to  Commissioning,  Improving  the  Ship  Design.  Acquisition  and  Construction 
Process:  Strategic  Plan".  Naval  Sea  Systems  Command.  Washington.  DC.  June  1991,  III-2.3.1 1. 
107  Fireman,  Fowler,  Mclntire  and  Wilkins,  "LPD  17:  In  the  Midst  of  Reform",  Naval  Engineers  Journal,  May  1995, 
page  267. 

CAPT  Dennis  Mahoney  (USN).  former  DD-21  Program  Manager,  interviews  during  Spring  1998. 
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4.4.1      Program  Management  Tasks 

Program  management  centers  on  five  key  areas:  planning  controlling,  organizing,  staffing  and  leading. 
Planning  includes  all  those  activities  associated  with  the  acquisition  strategy  and  program  schedule.  The  major  task 
element  for  program  management  in  a  modern  ship  design  program  is  the  Acquisition  Program  Baseline  (APB). 
The  APB  establishes  the  metrics  to  measure  performance,  cost  and  schedule  for  the  acquisition  program  and 
includes  objective  and  threshold  components.  The  APB  is  a  living  document  that  is  adjusted  and  acted  upon  based 
on  the  influence  of  design  changes,  warfare  requirements  and  schedule  pressures.  The  APB  is  the  primary 
documentation  for  review  and  approval  (SAR  and  DAES.)  The  APB  development  and  approval  process  is 
demonstrated  in  Figure  63.  Specific  instructions  for  preparation  of  the  APB  are  found  in  DoD  Directive  5000.2. 

Controlling  tasks  are  those  elements  necessary-  to  monitor  conformance  of  program  performance  to  the 
guidance  of  authorities  and  the  APB.  The  use  of  Cost/Schedule  Control  System  Criteria  (C/SCSC)  may  be  utilized 
to  "detect  a  deviation  from  the  plan,  (activate)  a  control  mechanism  to  bring  the  system  back  into  line."109 
Specifically,  controlling  requires  continual  audit  of  program  processes  to  monitor  and  correct  process  performance. 

Organizing  and  staffing  involve  the  management  of  personnel  and  manpower  budgets  with  respect  to  the 
design  process  needs.  This  is  a  major  systemic  force  in  the  design  process.  As  such,  it  is  explicitly  modeled  beyond 
tasking  requirements  (see  Chapters  5.4  and  5.5.) 

Finally,  leadership  is  the  major  function  of  the  program  management  staff.  The  ability  to  clearly 
communicate  desired  program  direction,  goals  and  needs  is  critical  to  program  performance.  Leading  the  program 
entails  continuous  information  gathering  and  evaluation  with  respect  to  the  forces  acting  to  control  the  program  (see 
Chapter  2).  As  a  result  of  the  program  managers  perceptions  of  those  forces,  he  or  she  must  respond  by  marketing 
the  good  aspects  of  the  program  and  addressing  concerns  to  responsible  authorities.  In  a  teaming  environment,  as 
proposed  by  IPPD/IPT,  program  leadership  means  the  ability  to  establish  and  maintain  consensus.  A  program 
manager  is  by  definition  the  leader  of  the  design  program,  and  it  is  his  or  her  continuous  role  (and  thus  tasking)  to 
lead  and  guide  a  successful  acquisition  program.  To  implement  leadership  over  all  aspects  of  the  project,  program 
management  will  naturally  require  input  and  output  connections  to  all  design  disciplines 


109  Defense  Management  College.  "The  Program  Managers  Notebook",  Fort  Belvoir,  VA.  June  1993. 
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Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Acquisition  Program  Baseline  (AP) 

Acquisition  Strategy 

Acquisition  Decision  Memorandum  (ADM)  & 
Defense  Acquisition  Executive  Summary  (DAES) 

Proqram  Management 

Milestone  Preparation  and  Exit  Criteria  Satisfaction 

Security  &  Security  Protection  Strategy 

Legal  Issues  Analysis 

Treaty  Compliance  Assessment 

SHAPM  Support  &  Special  Studies 

Design  History 

Design  Site  Management 

Hull  Engineering  Task  Group  Support 

Machinery  Task  Group  Support 

Design  Control 

Table  14  Program  Management  Tasking 

Based  on  analysis  of  the  DDG-51  program  and  other  surface  combatant  projects,  a  general  listing  of  program 

management  tasks  is  developed. 
Table  14  shows  the  appropriate  design  phase  during  which  specific  program  management  tasks  are  activated. 
It  is  assumed  that  tasks  are  updated  at  each  design  stage.  The  list  is  not  all-inclusive  (nor  are  later  lists  in  this 
chapter),  but  does  represent  those  primary  task  elements  required  by  directive  or  good  engineering  and  management 
practice  (see  Chapter  8.5.)  For  purposes  of  the  design  model,  the  given  quantity  of  tasks  (along  with  total 
programmatic  man-hours  expended)  provides  sufficient  aggregate  detail  to  model  process  behavior.  With  respect  to 
the  DSM  structure,  the  command  and  control  nature  of  program  management  necessitates  complete  input  from  and 
output  to  all  design  disciplines.  As  such,  the  row  and  column  is  unity  (see  Figure  28.) 

4.4.2      Requirements  Setting  and  Assessment 

The  second  program  task  element  is  the  interface  between  the  designers  and  the  warfighters:  requirements 
setting  and  assessment.  The  primary  concern  of  requirements  is  the  definition  of  the  defense-technical  problem  and 
translating  tins  problem  into  a  potential  design.  Chapter  1.1.2  specifically  addresses  the  current  mechanisms  being 
applied  to  improve  problem  definition  and  translation.  Additionally,  there  are  a  number  of  specific  design 
deliverables  that  relate  to  those  mechanisms.  The  Mission  Need  Statement  (MNS)  and  Operational  Requirements 
Document  (ORD)  are  the  initial  documents  produced  in  this  discipline.  The  MNS  in  a  non-system  specific 
statement  of  operational  capability.  The  ORD  formally  states  warfighter  objectives  and  minimum  acceptable 
requirements  for  operational  effectiveness  of  a  proposed  ship  concept  and  its  associated  systems.  Based  on  the 
requirements  of  the  MNS  and  ORD.  an  AoA  (formerly  COEA)  study  is  performed  to  analyze  potential  system 
options  sl  sfying  the  requirements.  The  AoA  as  defined  here  is  not  the  act  of  concept  engineering  analysis,  but 
rather  the  accumulation  of  information  developed  by  specific  engineering  disciplines  in  response  to  the  stated  needs 
of  the  MNS  and  ORD.  hi  other  words,  the  AoA  is  a  document  or  task  requirement,  not  a  process.  Instead  concept 
and  preliminary  design  are  the  processes  by  which  AoA  tasking  is  implemented.  Figure  61.  Figure  62.  and  Figure 
64  show  specific  processes  by  which  these  documents  are  prepared  and  reviewed.  These  requirements  and  post 
engineering  assessments  are  continually  audited  to  ensure  the  design  meets  the  needs  of  operational  forces. 
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When  deficiencies  are  discovered,  the  program  manager  has  three  primary  options:  modify  the  mission 
requirements,  re-initiate  the  design  to  achieve  the  stated  need,  or  introduce  an  engineering  change  to  achieve  the 
stated  need.  Modification  of  mission  needs  is  a  relatively  detailed  process,  but  can  be  effective  in  the  very  early 
stages  of  design.  This  is  particularly  true  during  concept  design  if  the  design  community  (in  conjunction  with  AoA 
tasking)  is  given  an  opportunity  to  present  operational  forces  with  specific  design  trades  enabled  by  requirement 
changes.  The  approaches  presented  in  Chapter  1.1.2  demonstrate  the  effectiveness  of  this  approach.  If  operational 
needs  cannot  be  changed,  then  the  design  may  need  to  be  re-initiated.  There  are  numerous  examples  of  this 
approach  in  the  last  few  years  as  a  result  of  changes  in  defense  doctrine  and  force  structure.  For  instance,  the  DDG- 
5 1  Flight  IIA  program  is  a  direct  result  of  a  need  to  produce  substantial  improvements  to  the  DDG-5 1  program 
following  decommissionings  of  numerous  combatant  ship  classes  during  the  early  1990's.  This  option  is  not 
practical  unless  the  design  process  is  still  young  (the  DDG-5 1  concept  design  process  lasted  four  years  for  this 
reason)  or  the  requirements  changes  preclude  reasonable  design  modification  within  the  current  program  (DDG-5 1 
Flight  IIA.)  When  changes  are  moderate,  then  engineering  change  proposals  (ECPs)  may  be  used.  Once  again, 
early  introduction  of  ECPs  is  preferred.  Due  to  the  long  duration  of  naval  ship  design  projects,  it  is  inevitable  that 
changes  are  required.  These  changes  have  well  documented  negative  impacts  on  the  design  process  (see  Chapter 
1.1.2.)  There  are  methodologies  which  can  minimize  the  impact  of  design  change  including:  Open  Architecture  and 
Modularity.110  Ultimately,  the  program  manager  must  decide  whether  the  timing  and  performance  gains  of  a  given 
design  change  outweigh  the  impacts  to  schedule  and  cost. 

For  the  purposes  of  the  naval  ship  design  model,  these  tasks  and  behaviors  are  incorporated  as  follows: 

1.  Tasks  profiles  are  set  per  those  listed  in  Table  15 

2.  ECPs  are  introduced  by  random  and/or  specified  task  growth  to  the  initial  tasks 

3.  The  fraction  of  task  growth  from  ECPs  is  directly  determined  by  the  first  order  impacts  of  the  scope 
growth  being  introduced  (i.e.  a  design  with  open  architecture  would  see  a  substantially  smaller  task 
fraction  increase  than  a  design  without  change  mitigation  mechanisms.) 

Like  the  structure  for  program  management,  requirements  setting  indicates  a  direct  output  to  all  design  tasks 
and  assessment  of  those  requirements  requires  input  from  all  tasks.  Thus,  the  DSM  structure  is  fully  populated. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Decision  Coordination  Paper  (DCPI 

Selected  Acquisition  Report  (SAR) 

Congressional  Data  Sheet  (CDS) 

Mission  Need  Statement 

Operational  Requirments  Document  (ORD)  &  Requirements  Setting 

System  Concept  Paper  (SCP)  &  Design  Review/Report 

System  Threat  Assessment 

COEA/Analysis  of  Alternatives 

Engineering  Change  Proposals  (ECP)  &  "External"  Change  Requests 

Table  15  Requirements  Setting  and  Assessment  Tasks 


no 


MIT  Course  13.64.  "CVX  Product  and  Process  Planning".  Massachusetts  Institute  of  Technology.  Cambridge, 
MA  Summer  1997,  page  70 
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4.4.3      Risk  Mitigation  and  Coordination 

The  final  category  of  programmatics  is  that  set  of  tasks  which  provides  analysis  of  potential  program  risks 
and  coordinates  technology  development  with  other  defense  programs.  Primary  tasks  in  this  category  are: 
Development  Test  and  Evaluation  (DT&E),  Test  &  Evaluation  Master  Plan  (TEMP),  Live  Fire  Test  &  Evaluation 
(LFT&E)  analysis.  Safety  analysis  and  coordination  efforts  for  Research,  Development,  Test  and  Evaluation 
(RDT&E).  DT&E  determines  the  potential  variability  in  effectiveness,  cost  and  schedule  associated  with 
technologies  under  consideration  for  the  design.  If  the  technologies  are  too  risky  for  consideration,  fall-back  options 
are  explored  to  allow  the  design  to  proceed.  DT&E  changes  can  impact  the  design  rates  through  the  introduction  of 
delayed  tasks  (technologies  maturing  behind  schedule)  or  scope  change  (transition  of  the  program  to  the  fallback 
position  or  introduction  of  a  newly  maturing  technology.)  Even  after  specific  technologies  are  introduced  into  the 
design,  it  is  necessary  to  develop  a  schedule  to  evaluate  the  effectiveness  of  the  technology  as  integrated  in  the  ship 
design.  Specifically,  the  TEMP  and  LFT&E  provide  the  structure  to  test  system  effectiveness.  As  known  and 
perceived  risks  relative  to  the  technology  or  capability  are  disclosed,  the  plans  must  adapt.  An  increasingly 
important  method  of  risk  reduction  is  coordination  of  RDT&E  with  other  programs.  In  particular,  early  R&D 
projects  must  be  monitored  to  ensure  compatibility  with  ship  design  development  and  mission  needs.  For  more 
advanced  technology  programs.  Ship  Acquisition  Managers  (SHAPMs)  must  coordinate  efforts  with  Participating 
Managers  (PARMs).  Once  again,  changing  technology  schedules  and  capabilities  may  impact  the  design  process. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Risk  Assessment 

1 

1 

1 

1 

1 

Programmatic  Measures  of  Effectiveness  Analysis  (Cost  Schedule  & 
Performance  Risk  Analysis) 

1 

1 

1 

1 

1 

DT&E  Report 

1 

1 

1 

1 

1 

Environmental,  Safety  &  Health  Evaluation 

1 

1 

1 

1 

1 

Technology  &  Industrial  Capability  Assessment  (Commercial  &  NDI 

Evaluation  &  Status) 

1 

1 

1 

1 

1 

Cooperative  Opportunities  Assessment 

1 

1 

, 

1 

1 

Integrated  R&D 

1 

1 

1 

1 

1 

Test  &  Evaluation  Master  Plans  (TEMP) 

1 

1 

1 

1 

1 

LFT&E  Waiver  Certificate 

1 

1 

1 

1 

1 

LFT&E  Report 

1 

1 

1 

1 

1 

Computer  Applications  &  Support,  Information  Technology  Architecture 

1 

I 

! 

1 

1 

Information  Technology  Statutory  Compliance  (Information  Technology 

Management  Reform  Act  (ITMRA),  Government  Performance  and  Results 

Act  (GPRA),  Paperwork  Reduction  Act  (PRA)) 

1 

1 

1 

1 

1 

System  Safety  Study 

1 

1 

1 

1 

Table  16  Risk  Mitigation  and  Coordination  Tasks 


For  the  purposes  of  the  naval  ship  design  model,  these  tasks  and  behaviors  are  incorporated  as  follows: 

1 .  Tasks  profiles  are  set  per  those  listed  in  Table  16 

2.  Changes  resulting  from  technology  changes  are  introduced  by  random  and/or  specified  task  growth  to  the 
initial  tasks 

The  DSM  structure  for  risk  mitigation  deviates  slightly  from  previous  programmatic  tasks.  Process  flows 
indicate  that  although  risk  tasking  is  performed  for  specific  engineering  disciplines  (hull,  machinery,  payloads. 
system,  cost),  the  risk  analysis  information  is  delivered  tlirough  program  management  and  requirements  rather  than 
directly  to  the  responsible  disciplines.  In  this  manner,  risk  mitigation  and  coordination  acts  as  an  information 
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control  gate  during  feedback  of  design  attributes.  As  assessments  of  requirements  against  presented  design 
parameters  are  assimilated  the  elements  of  risk  mitigation  incorporate  those  values.  If  specific  risk  analysis 
indicates  concerns  or  necessary  coordination,  then  modifying  information  will  flow  back  to  those  disciplines  that 
perform  physical  design  (hull  geometry,  mechanical  systems,  mission  systems,  etc.) 

4.5       Systems  Engineering 

The  second  design  process  node  is  systems  engineering.  It  is  important  to  differentiate  systems  engineering 
as  discussed  in  Chapter  3  from  this  process  node    System  engineering  as  discussed  previously  represents  the 
overarching  optimization  of  cost,  effectiveness  and  schedule  to  meet  a  need.  In  this  context,  the  naval  ship  design 
process  is  a  subset  of  systems  engineering.  How  ever,  within  naval  ship  design  is  an  alternative  systems  engineering 
definition.  In  this  context,  systems  engineering  represents  those  engineering  disciplines  required  to  integrate 
specific  ship  design  components  (hull  systems,  mechanical  systems,  and  combat  systems),  to  analyze  the  integrated 
components  in  the  system  (Integrated  Logistics  Support  (ILS).  contract  specifications,  producibility,  manning)  and 
to  compare  the  system  performance  against  requirements  (mission  effectiveness.)  In  this  context,  systems 
engineering  has  evolved  over  the  last  40  years  to  become  a  key  element  of  the  design  process.  Initial  formalization 
of  systems  engineering  began  in  the  1950's  on  the  first  ballistic  missile  programs.  During  the  1970's,  systems 
engineering  achieved  true  maturity  in  the  Aegis  Weapons  Program  (1970s)  under  the  guidance  of  ADM  Wayne 
Meyers  (USN  retired.)  During  an  interview  with  ADM  Meyers111,  he  made  the  following  comments  regarding  the 
impacts  of  systems  engineering  on  the  overall  design  process: 

1.  "Warships  are  inherently  inefficient  design  exercises."  Due  to  the  scope  of  surface  combatant  design 
projects,  individual  design  components  are  rarely  optimized  in  the  context  of  system  impacts.  For 
instance,  component  optimization  generates  vast  numbers  of  supplier-vendors.  A  large  vendor  base 
requires  complex  supply  chains  which  de-optimize  ILS  and  life  cycle  cost.  Until  effective  system 
optimization  is  reahzed  (see  Chapter  1.1.2).  component  development  will  continually  generate 
divergences  in  systems  development. 

2.  "Program  managers  don't  know,  only  perceive,  the  true  status  of  the  fiscal,  technical,  temporal  vectors." 
The  goal  of  the  program  manager  is  to  focus  the  project  towards  convergence.  However,  uncertainties  in 
information,  variations  in  cost,  and  delays  in  progress  cause  the  vectors  to  diverge.  In  systems 
engineering,  this  is  even  more  critical  as  the  integration  of  components  is  constantly  varying  w  ith  the 
variable  schedules  and  complexities  of  those  components  (Figure  23  and  Table  9.)  Coupled  productivity 
and  varying  development  rates  produce  delays  in  systems  development. 

3 .  "Knowledge . . .  Engineering.  Cost,  etc . . .  must  be  accumulated  and  tapped  to  facilitate  systems 
integration."  Systems  engineering  is  the  cap-stone  of  the  naval  engineering  process.  To  effectively  pull 
together  the  elements  of  the  system,  time  and  patience  are  necessary.  Unfortunately,  time  is  also  the 
enemy  of  the  design  process . . .  time  generates  changing  requirements  and  changing  technologies.  To 


in 


ADM  Wayne  Meyers  (USN  retired),  interview  on  November  14.  1997.  Arlington,  VA. 
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understand  systems  engineering  one  must  acknowledge  the  impact  of  time ...  early  work  is  undone,  later 
work  will  require  iteration  back  to  the  component  level,  and  very  late  work  will  introduce  scope 
increases  which  can  diverge  the  program. 
Baseline  (DDG-51)  task  levels  and  productivity  levels  for  Systems  Engineering  are  presented  in  Chapter  8.5. 

4.5.1      Logistics  and  Reliability  Engineering 

Integrated  Logistics  Support  (ILS)  and  Reliability,  Maintainability  and  Availability  (RMA)  assessment  are 
the  disciplines  that  may  most  greatly  determine  the  life  cycle  cost  and  operational  effectiveness  of  the  ship  design. 
ILS  is  a  management  and  technical  approach  that  integrates  support  considerations  into  system  and  equipment 
design.  Support  requirements  are  determined  by  readiness  objectives,  current  and  planned  supply  chains  (underway 
replenishment,  storage,  supply  overhead,  packaging,  handling),  maintenance  plans,  manning  levels,  and  training 
pipelines.  RMA  (also  known  as  RAM)  is  a  complement  to  ILS.  RMA  analysis  determines  the  level  of  ILS  required. 
Specifically.  RMA  assesses  operational  functionally  for  the  ship,  redundancy  versus  reliability,  and  the  ease  of 
recover}'  of  systems  that  do  fail  (relative  to  ILS  and  maintainability.) 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Inteqrated  Logistic  Support  &  Maintenance  Analyss 

1 

1 

1 

1 

1 

1 

1 

Reliability,  Maintainability  and  Availability  (RMA)  Assessment 

1 

1 

1 

1 

1                        1 

1 

Table  17  Logistics  and  Reliability  Engineering  Tasks 

RMA  and  ILS  are  highly  coupled  disciplines.  As  such,  it  is  not  unreasonable  to  assign  a  value  of  1  to  the 
diagonal  for  DSM  (see  Chapter  4.1.)  However,  the  value  of  0  is  assigned  to  maintain  consistency  with  DSM 
methodology.  Input  values  are  required  from  those  disciplines  that  impact  maintenance,  reliability  and  support 
including:  requirements,  manning,  hull  structures,  arrangements,  mechanical  and  mission  systems.  The  results  of 
ILS  and  RMA  feed  programmatics  for  action,  if  necessary.  Additionally,  results  provide  input  to  producibility  (ILS 
has  a  first  order  impact  on  production  methods)  and  to  performance  (RMA  is  an  input  for  Ship  Vulnerability 
Modeling  (SVM)  and  operational  effectiveness  measures.) 

As  would  be  expected.  ILS  and  RMA  should  be  started  from  the  initiation  of  the  design  in  order  to  achieve 
the  greatest  leverage  over  life  cycle  cost  (LCC).  Table  17  shows  the  progression  of  ILS  and  RMA  tasks.  Past  design 
programs  minimized  the  early  ILS  and  RMA  effort   This  can  be  seen  by  the  small  man-months  per  task  during 
concept  and  preliminary  design  shown  in  Chapter  8.5.  Given  current  ILS  trends,  there  is  increased  need  for  early 
analysis.  Figure  3 1  shows  the  exponential  growth  experienced  in  ILS  overhead  measured  as  increasing  parts  listings 
( APL's.)  With  increasing  parts  and  supply  trains,  ILS  becomes  an  increasingly  greater  fraction  of  LCC.  As  shown 
in  Figure  32,  the  primary  ILS  components  (manning  and  maintenance)  constitute  almost  60%  of  the  LCC.  Recent 
efforts  to  counter  the  trend  (such  as  Affordability  Through  Commonality  (ATC)  and  open  systems  architecture) 
show  promise.  Applied  to  current  design  programs,  these  efforts  provide  substantial  cost  savings,  but  require  greater 
man-hour  efforts  in  early  design.  For  the  baseline  design  model,  DDG-51  ILS  task  efforts  are  used.  However, 
future  '"what-if '  scenarios  should  reflect  increased  efforts  in  early  stage  design.  This  would  provide  program 
managers  with  a  comparison  of  life  cycle  cost  savings  versus  the  impact  on  schedule  and  resources. 
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Numbers  of  APL's 
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Figure  31  Trends  for  Applicable  Parts  Lists  (APL's)  for  Surface  Combatant  Designs 
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Figure  32  Life  Cycle  Cost  Components  for  Typical  Naval  Ships 
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4.5.2      Design  Integration  and  Specifications 

Design  integration  and  specifications  arc  the  means  by  which  the  design  achieves  system  definition  and  seeks 
to  maintain  designed  performance  in  subsequent  iterations.  In  the  early  stages  of  design,  systems  engineering 
decisions  are  meant  to  define  the  overall  ability  of  concepts  to  satisfy  expectations  for  total  system  effectiveness.  As 
specific  ship  components  (hull,  prime  movers,  combat  system  elements)  are  considered  in  the  design,  these  elements 
must  be  optimized  relative  to  one  another  and  relative  to  mission  requirements.  As  design  iterations  are  generated, 
there  may  be  the  tendency-  of  component  engineers  to  continuously  change  in  response  to  changing  input 


~  Todd  Can.  Naval  Sea  Systems  Command,  interview  on  August  27,  1997.  Arlington.  VA. 
Ryan  and  Jons,  "Improving  the  Ship  Design.  Acquisition  and  Construction  Process" ,  Association  of  Scientists 
and  Engineers.  28th  Annual  Technical  Svmposium,  11  April  1991.  page  13. 
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information  from  other  component  elements    Without  mechanisms  to  manage  these  changes,  it  is  likely  that  the 
design  would  diverge.  This  is  the  role  of  systems  integration.  Through  the  use  of  margins  (see  Chapter  1.1.3)  and 
configuration  control,  design  managers  restrict  the  degree  of  change  permitted  over  time.  Configuration  control 
(managed  by  means  of  a  baseline  3-D  product  model,  equipment  lists,  performance  specifications,  military 
specification,  issuing  arrangement  drawings,  etc)  provides  a  design  baseline  that  "freezes"  those  aspects  of  the 
design  viewed  as  satisfactory  with  respect  to  the  requirements. 

In  later  design  stages,  design  integration  matures  beyond  configuration  specification  to  component 
specification.  Earlier  discussions  (see  Chapters  3.3.1  and  4.4)  demonstrate  the  changing  roles  of  contract 
specifications  in  the  design  process.  However,  the  selection  of  components  and  their  exclusion  from  further  design 
change  must  take  place  in  the  design  process,  whether  dictated  by  the  government  during  contract  design  or  by 
industry  m  functional  design.  Ultimately,  the  design  must  be  specified  in  order  to  allow  production. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Systems  Engineering,  Design  Integration  &  Configuration  Control 

1 

1 

1 

1 

Ship  &  Purchase  Specifications,  GFE/GFI  &  CDRLs 

1 

1 

1 

Specification  Design  History  Input 

1 

1 

1 

GFE'GFI/VFI  Specification 

1 

1 

Design  Control 

Table  18  Design  Integration  and  Specification  Tasks 

Table  1 8  provides  a  listing  of  the  specific  design  tasks  associated  with  design  integration  and  specification. 
Note  that  these  task  effort  profiles  (Chapter  8.5)  would  likely  change  for  a  current  design  program  to  reflect  a 
changing  government  to  industry  design  transition  point  (see  Figure  5).  However  the  task  elements  (with  perhaps 
different  names)  would  still  remain. 

The  input  requirements  for  design  integration  include  those  elements  of  the  process  that  are  specific  to  design 
definition  (hull,  structures,  marine  systems,  combat  systems.)  The  design  integration  tasking  receives  the  inputs  of 
current  design  parameters  and  outputs  constraints  to  the  program  manager  for  implementation. 

4.5.3      Producibility  and  Production  Engineering 

Producibihty  and  production  engineering  is  the  consideration  of  industrial  capabilities  relative  to  ship  design 
and  construction   Tins  requires  both  the  assessment  of  industrial  capabilities  relative  to  technologies  incorporated  in 
the  design  and  inclusion  of  "design  for  production"  elements  in  the  design.  To  the  first  requirements,  the  industrial 
base  necessary  to  support  naval  ship  design  and  construction  must  be  assessed.  For  instance,  there  only  a  few 
shipbuilders  with  facilities,  knowledge  and  skills  available  to  produce  specialized  hullforms  (such  as  submarines)  or 
to  test  advanced  combat  systems  (such  as  the  Aegis  Weapons  System.)  The  selection  of  specific  ship  design  options 
(such  as  materials,  size,  weapon  systems,  etc)  will  naturally  reduce  the  field  of  potential  builders.  The  introduction 
of  new  technologies  may  further  reduce  the  capable  industrial  base.  It  is  a  necessary  task  of  design  managers  to 
understand  the  impacts  of  technology  and  design  on  the  shipbuilders.  Secondly,  design  for  production  must  be 
included  to  achieve  the  cost  goals  described  in  Chapter  1.1.3.  Specifically,  the  design  must: 

1      Develop  a  build  strategy  and  product  work  breakdown  structure. 
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2.  Assess  the  design  against  the  production  process 

3.  Incorporate  appropriate  producibility  enhancements. 

It  is  apparent  that  this  process  of  design  for  production  is  itself  a  closed  loop  system  that  seeks  to  optimize  cost  and 
production  effectiveness  relative  to  military  effectiveness. 

It  is  noted  that  design  for  production  considerations  were  not  adequately  included  in  past  designs.  Due  to 
requirements  for  competition.  US  yards  have  not  been  able  to  incorporate  producibility  to  the  extent  necessary  to 
realize  savings.  Consider  Table  19.  In  foreign  yards,  designs  are  specifically  tailored  to  the  capabilities  of  the  yards 
and  their  workers.  As  such,  even  in  countries  where  workers  are  paid  more,  the  labor  required  to  produce  a  ship  and 
the  total  labor  costs  are  less.  Consider  the  design  task  elements  for  the  DDG-5 1,  and  hence  the  baselme  naval  ship 
design  process  model,  shown  in  Table  20.  The  ship  work  breakdown  structure  was  not  formalized  until  late  in  the 
process.  Again  demonstrating  the  lack  of  producibility  consideration  in  the  final  design. 


Productivity 

Japan 

Korea 

Germany 

US 

Employee-Days/Ship 

45,000 

99.000 

65.000 

100.000 

Hourly  Compensation  (1990  US  Dollars) 

16.0 

7.8 

26.5 

15.6 

Total  Labor  Charges  ($  million) 

5.76 

6.17 

13.78 

12.48 

Table  19  Shipyard  Productivity  Comparison  for  Comparable  Ship  Designs114 

There  are  significant  efforts  to  change  this  trend  and  to  incorporate  producibility  much  earlier  in  the  design 
process.  For  instance,  the  LPD-17  hullform  design  was  enhanced  with  large  flat  plate  construction,  single  curvature 
midbody  and  an  elliptical  bulbous  bow  (no  fillet)."5  These  enhances  are  a  step  in  the  direction  of  enhancing 
producibility.  Current  programs  will  further  improve  producibility  by  incorporating  shipbuilders  at  the  earliest 
stages  of  design. 

To  maximize  the  leverage  of  producibility'  on  cost,  a  ship  design  must  be  optimized  from  the  concept  phase 
onward  not  only  for  mission  needs  and  operational  cost,  but  also  for  production  schedule  and  construction  cost. 
Producibility  tasking  may  take  several  forms,  but  two  are  generally  observed.  First,  producibility  is  assessed  relative 
to  fabrication,  arrangements  and  materials.  For  those  designs  that  are  optimized  for  a  particular  shipyard's 
capabilities,  ship  arrangements  (outfitting,  block  sizes,  etc)  and  materials  and  fabrication  (common  material 
catalogue,  limiting  complex  shape  geometry)  enhance  productivity  for  the  shipbuilder.  Improved  productivity 
means  lower  costs,  better  quality  and  shorter  production  schedules. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Industrial  Facilities  Design  and  Industrial  Base  Assessment  (BASE) 

1 

1 

1 

1 

1 

1 

1 

Producibility,  Fabrication  &  Materials  Assessment 

1 

1 

1 

1 

1 

1 

Ship  Work  Breakdown  Structure 

1 

1 

1 

1 

Table  20  Producibility  and  Production  Engineering 


Rost  and  Tighe,  1992  Shipyard  Costs  and  Capabilities,  Center  for  Naval  Analysis.  Alexandria.  VA. 


114 

115  Fireman.  Fowler,  Mclntire  and  Wilkins.  "LPD  17:  In  the  Midst  of  Reform",  Naval  Engineers  Journal.  May  1995. 
page  275. 
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However,  competitive  requirements  of  contracts  necessarily  limit  the  level  of  producibility  optimization  that 
can  occur.  For  this  reason,  a  second  method  of  producibility  assessment  has  been  developed:  Generic  Work 
Breakdown  Structure  (G WBS).  As  its  name  implies,  the  method  provides  a  generic  method  of  assessing 
producibility.  The  method  is  centered  around  group  technology  construction  and  organization  of  design  elements 
into  families  of  structures  and  components."6  For  early  design  (pre-contract  award)  the  method  provides  a  tool  to 
assess  production  impacts  of  design  decisions  and  to  minimize  costs  where  possible. 

For  the  design  model.  Table  20  provides  the  baseline  progression  of  design  tasks.  Again,  current  design 
programs  will  see  variations  in  the  timing  of  design  tasks  and  growth  in  the  levels  of  producibility  tasks. 
Dynamically,  producibility  incorporates  specific  ship  characteristics  (hull  geometry,  structural  design,  arrangements, 
machinery  and  payload  components)  to  assess  construction  impacts.  The  output  of  producibility  is  assessed  at  the 
management  level.  Additionally,  producibility  is  a  key  input  factor  to  cost  assessment. 

4.5.4      Performance  Assessment  and  Requirements  Comparison 

Performance  assessment  includes  modeling  design  characteristics  as  a  total  system,  calculating  ship's 
performance  based  on  total  ship  design  parameters,  and  assessing  the  mission  effectiveness  relative  to  requirements. 
Performance  assessment  has  improved  in  recent  years  through  unprovements  in  computer  modeling  capabilities. 
Specifically.  Survivability  and  Vulnerability  Modeling  (SVM).  Electromagnetic  Workstation  (EMW)  models. 
Leading  Edge  Advanced  Prototyping  for  Ships  (LEAPS),  and  others  provide  increasingly  robust  environments  to 
test  system  performance  and  effectiveness."    These  models  are  the  initial  steps  of  a  trend  towards  simulation  based 
design  (SBD.)  Although,  most  levels  of  performance  assessment  still  require  physical  modeling  (such  as  hullform 
testing  in  towing  tanks),  improved  computer  modeling  will  eventually  provide  the  means  to  test  all  performance 
requirements  in  the  virtual  environment. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Survivability  &  Vulnerability  Assessment 

1 

Concept  Performance 

1 

Damage  Control  System  Design 

1 

NBC  (CBR)  Defense 

1 

Combat  System  Performance  Assessment 

Table  21  Performance  Assessment  and  Requirements  Comparison  Tasks 

Table  2 1  shows  a  progression  of  performance  tasking  that  was  performed  for  the  DDG-5 1  program.  The  DD- 
21  program  will  include  mission  effectiveness  assessment  and  task  efforts  such  as:  Extended  Air  Defense  Simulation 
Model  (EADSIM).  Surface  AAW  Multi-Ship  Simulation  (SAMS).  Naval  Air  Battle  Engagement  Model  (NABEM 
II),  Radar  Analysis  Model  (RAM).  ASW  Programs  Surface  Ship  Engagement  Model  (APSURF).  and  Generic  Sonar 
Model  (GSM)."8 


116 


Storch,  Hammon.  Bunch  and  Moore.  Ship  Production.  Society  of  Naval  Architects  and  Marine  Engineers.  Jersey 
City,  NJ,  1995.  page  60. 

Myles  Hurwitz,  'Leading  Edge  Advanced  Prototyping  for  Ships  (LEAPS):  an  Integrated  Architecture  for  Early 
Stage  Ship  Concept  Assessment  Software'",  David  Taylor  Research  Center.  Bethesda,  MD.  1997. 


DD-21  Program  Website,  http://www.navsea.naw.mil. 
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Like  other  systems  engineering  disciplines,  performance  assessment  requires  input  from  all  design  definition 
disciplines.  However,  the  output  of  assessment  is  often  provided  directly  to  designers.  This  is  particularly  true  in 
the  real-time  design  and  selection  of  specific  design  characteristics  such  as  arrangements,  hull  and  deckhouse 
configuration  and  topside  arrangement  of  combat  systems. 

4.5.5      Manning 

Manning  assessment  and  definition  is  the  final  discipline  of  systems  engineering.  Manpower  studies  begin 
with  comparative  estimates  of  ship  functions  to  similar  ship  designs.  Later  studies  provide  detailed  manning  studies 
based  on  functional  breakdowns  of  maiming  requirements.  As  manning  levels  are  established  for  specific  ship 
watch  stations,  human  engineering  are  conducted  to  optimize  human  performance  relative  to  mission  performance. 

For  many  years,  manning  was  viewed  as  a  non-constraining  attribute.  Namely,  shipboard  manpower  was 
viewed  as  unlimited.  Damage  control,  condition  I  watch  stations  and  maintenance  requirements  often  drove 
manning  levels  well  above  those  levels  required  for  daily  operations.  However,  the  fiscal  need  for  reduced 
operational  costs  and  the  political  desire  to  limit  human  exposure  to  threat  environments  now  results  in  imposed 
manning  levels.  If  this  trend  continues,  manning  assessment  becomes  increasingly  important  to  both  system  and 
component  design 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Manpower  Estimate 

1 

1 

1 

1 

1 

1 

1 

Manning  iTyav 

1 

1 

1 

1 

1 

1 

1 

Shio  Manning  Document 

1 

1 

1 

1 

1 

1 

Human  Systems  (Factors)  Engineering 

1 

1 

1 

1 

1 

1 

Table  22  Manning  Assessment  Tasks 

Table  22  shows  the  progression  of  manning  tasks.  These  tasks  require  input  primarily  of  those  ship 
characteristics  that  impact  human  engineering  and  manning  requirements  including,  ship  arrangements  and  sizing, 
machinery-  systems  and  combat  systems.  Early  output  from  manning  impacts  sizing  of  the  hull,  payloads  and 
auxiliary  systems.  Later  output  provides  specific  requirements  for  accommodations  (arrangements),  machinery 
system  modifications  for  human  support  and  second  order  changes  (changing  maintenance  requirements  or  selection 
of  new  equipment  items)  tlirough  program  management. 

4.6       Hull  Engineering 

The  hull  engineering  node  is  itself  a  significant  systems  engineering  effort.  Naval  architects,  the  primary 
participants  in  hull  engineering,  often  claim  the  title  of  the  "worlds  first  systems  engineers."119  Specifically,  hull 
engineering  must  balance  weight,  buoyancy,  area,  power  and  resistance  while  maintaining  adequate  static  and 
dynamic  stability  and  strength,  both  in  intact  and  damaged  conditions.  Specific  design  spirals  are  developed  to 
balance  these  characteristics.  For  instance,  the  MIT  Math  Model  -  FFX1  :o.  balances  hull  characteristics,  deckhouse 


Tibbitts  and  Keane.  "Naval  Ship  Design  in  the  21st  Century",  Society  of  Naval  Architects  and  Marine  Engineers, 
Jersey  Citv,  NJ,  1993. 
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Brown  and  Welsh,  MIT  Math  Model  -  FFX.  Massachusetts  Institute  of  Technology  course  13.412.  fall  1996. 


volume  and  power  for  fixed  inputs  of  marine  systems,  combat  pa\  loads,  mission  requirements,  and  manning.  The 
original  design  spiral  developed  by  Prof.  Evans  performed  a  similar  optimization  for  commercial  ship  designs    A 
specific  examination  of  equations  and  physical  relationships  for  hull  design  and  engineering  are  beyond  the  scope  of 
this  work.  Rather,  the  nature  of  the  component  design  disciplines  and  their  purposes  relative  to  the  design  process 
are  discussed. 

It  is  important  to  note  a  general  change  in  hull  engineering  disciplines  over  the  past  decades.  In  the  past, 
arrangements  and  hull  geometry  and  powering  were  often  separate  exercises  from  hydrostatic  and  hydrodynamic 
analysis.  Although  it  was  possible  that  the  same  individual  or  group  of  individuals  might  perform  the  design  and 
analysis  tasks,  the  considerable  manual  effort  required  to  perform  those  tasks  would  necessarily  cause  them  to  be 
performed  independently.  This  fact  is  apparent  in  IDEF  charts  and  design  spirals  depicting  very  linear  and  distinct 
nodes.  For  instance.  Prof.  Evans  design  spiral  generates  a  basic  ship  design  from121 : 

1 .  Proportions  and  Powering  Estimates 

2.  Lines  and  Body  Plans 

3.  Hydrostatics  and  Bonjeans 

4.  Floodable  Length  and  Freeboard 

5.  Arrangements 

6.  Structures 

7.  Powering  Light  Ship  Weight  Estimates 

8.  Capacities.  Trim  and  Intact  Stability 

9.  Damaged  Stability 

10.  Comparisons  to  Cost  and  Owners  Requirements 

11.  Next  Iteration... 

This  indicates  an  algorithm  by  which  design  disciplines  are  separated  or  design  tasks  are  linear.  However,  today's 
design  tools  are  allowing  seamless  design  and  analysis  with  real-time  iteration  and  feedback.  For  instance,  hull 
geometry  software  often  includes  modules  to  create  hullforms.  assess  resistance,  generate  hydrostatic  properties, 
assess  maneuverability  and  determine  seakeeping.  These  integrated  packages  allow  a  single  designer  to 
immediately  see  the  impact  of  a  hull  geometry  change  on  resistance  or  buoyancy.  Inclusion  of  internal  properties 
(hull  subdivision,  weight  distributions  and  tank  placements)  allow  a  designer  to  perform  major  arrangements  and 
assess  those  choices  for  stability.  Obviously,  the  advantage  of  the  integrated  environment  is  fewer  design  errors, 
reduced  communication  overhead,  and  greater  productivity. 

Based  on  the  DDG-51  program  data,  some  integrated  design  and  analysis  was  available  in  concept  design. 
However,  this  was  less  apparent  in  preliminary  design  and  beyond.  As  such,  the  current  model  considers  the  efforts 
of  hull  engineering  as  separate  disciplines.  Future  variations  of  the  design  process  model,  may  reflect  the  integrated 
environment  through  a  merging  of  design  disciplines.  However,  design  tasking  will  not  entirely  merge  as  detailed 
design  tasks  (such  as  structural  engineering  and  arrangements)  arc  still  specialized  disciplmes  requiring  separate 


J.  Evans.  "Basic  Design  Concepts".  Naval  Engineers  Journal.  November  1959. 
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design  actions.  For  instance,  Newport  News  Shipbuilding  uses  an  integrated  software  environment  (VIVID  system 
using  a  3D  product  model)  in  detailed  design.122  Although  the  system  provides  a  common  interface  and  model 
information  is  fully  accessible  to  all  designers,  the  design  team  still  requires  separate  structural  designers,  weight 
engineers,  arrangement  specialists,  etc. . .  to  perform  specific  design  tasks,  and  discuss  design  and  analysis  results  in 
a  team  environment. 

The  task  and  productivity  hull  design  levels  for  the  baseline  case  (DDG-5 1  program)  are  provided  in  Chapter 
8.5.  The  justification  for  the  DSM  is  provided  below. 

4.6.1      Hull  Geometry 

Hull  geometry  is  the  cornerstone  of  hull  engineering.  Hull  geometry,  or  the  ship's  lines,  must  meet  "precise 
and  unambiguous"  design  constraints  . .  and  will  "consist  of  orthographic  projections  of  the  intersections  of  the  hull 
form  with  three  mutually  perpendicular  sets  of  planes"123  As  simple  as  that  may  sound,  the  process  is  quite 
complex.  The  selection  of  specific  hull  parameters  (length,  beam,  draft),  hull  coefficients  (prismatic,  waterplane. 
block,  midship  section),  and  fairing  of  hull  lines  requires  iteration  and  trade-off.  To  facilitate  early  design, 
parametrics  and  established  design  lanes  are  often  utilized  to  estimate  hull  size  and  shape.124  These  parameters 
typically  require  estimates  of  weights,  weight  distribution  and  desired  hull  speed  as  inputs.  The  parameters  are  then 
iterated  for  convergence  against  requirements.  More  advanced  hull  geometry  algorithms,  such  as  the  HULGEN 
program  in  ASSET,  combme  parametric  selections  for  baseline  sizing  with  a  parent  hull  design  to  fair  intermediate 
station  values  to  the  hull  parameters  and  coefficients.  These  methods  provide  a  consistent  basis  for  concept  trade- 
off and  perturbations.  However,  critics  point  out  that  use  of  design  lanes  constrain  innovation. 

At  the  preliminary  design  stage,  hull  geometry  uses  3-D  graphical  modeling  and  scale  model  construction. 
As  with  performance  assessment  (Chapter  4.5.4).  hull  geometry  design  matured  greatly  with  the  introduction  of 
modeling  programs  like  Hull  Form  Definition  System  (HFDS)  with  its  integrated  generation  and  manipulation 
modules  (FastShip.  FASTGEN,  and  I/VDS.)12?  These  programs  provide  increased  ability  to  both  generate  and 
optimize  hull  forms  relative  to  resistance,  particularly  for  monohull  designs   Other  hull  performance  analysis,  like 
seakeeping  and  stability,  is  also  facilitated  by  common,  digital,  hull  geometry  definitions.  Unusual  hullforms.  such 
as  multi-hull  designs  or  the  wave  piercing  bow,  must  still  be  physically  modeled  and  tested.    Such  testing  not  only 
supports  the  current  design,  but  provides  calibrating  data  for  future  computer  modeling. 

In  addition  to  the  basic  hull  geometry,  other  hull  characteristics  may  be  selected  and  modeled  to  enhance 
performance.  For  instance,  bow  (like  the  bulbous  bow)  and  stem  configurations  are  optimized  to  reduce  resistance 
while  maintaining  adequate  seakeeping  characteristics. 


122  Scott  Ripley.  Interview  at  Newport  News  Shipbuilding.  Newport,  VA,  August  29,  1997. 

Normal  Hanlin.  "Ship  Geometry",  Principles  of  Naval  Architecture,  Society  of  Naval  Architects  and  Marine 
Engineers,  Jersey  City,  NJ.  1988,  Volume  I  page  1. 

'A  Gale  and  Scott.  "Early  Stage  Ship  Design  Seminar",  Society  of  Naval  Architects  and  Marine  Engineers.  Jersey 
City,  NJ,  1988. 

'5  Whatmore  and  Wintersteen.  A  Review  of  Extant  Design  Tool  Capabilities  to  Identify  Common  Design  Tools  for 
Future  Collaboration.  Naval  Surface  Warfare  Center  Carderock  Division.  Bethesda,  MD.  1997.  page  20. 
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Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Principle  Dimensions 

1 

Parent  Ship  Properties 

1 

Hullform 

1 

Lines  Drawings 

1 

3-D  Model 

Curves  or  Form 

Hull  Design  Specrfications  Input 

Hull  Design  History  Input 

Model  Test  Plan  and  Model  Constructon  Plan 

Stern  Reconfiguration 

Table  23  Hull  Geometry  Tasks 

Table  23  shows  the  progression  of  hull  geometry  tasks  in  the  design  process.  As  discussed  above,  initial 
tasks  are  parametrically  generated.  The  inputs  includes  weights,  mechanical  and  combat  systems,  and  requirements 
(speed,  resistance,  stability).  Hull  geometry  represents  a  field  of  pure  design.  In  other  words,  hull  geometry  is  the 
definition  of  ship  characteristics  without  explicit  performance  analysis  (hull  performance  analysis  is  addressed  as 
separate  disciplines.) 

Generally,  all  disciplines  may  be  categorized  as  pure  design,  pure  analysis  (a  discipline  that  describes  the 
performance  of  a  design  characteristic,  but  does  not  necessarily  have  the  capability  or  authority  to  modify  that 
characteristic)  or  some  combination  of  design  and  analysis.  As  a  pure  design  discipline,  hull  geometry  must  provide 
hull  engineering  input  to  analysis  disciplines  which  include:  weight  engineering,  hydrodynamics,  structures,  marine 
engineering,  cost  and  programmatics. 

4.6.2      Weight  Engineering 

Weight  engineering  is  a  discipline  of  assessment  and  design.  Weight  engineering  estimates  distribute  and 
account  for  mass  distributions  in  the  ship.  In  early  design  iterations,  these  distributions  may  be  purely  empirical 
with  only  a  few  mass  locations  (such  as  engines  or  combat  systems)  explicitly  known.  As  the  design  matures, 
weight  engineering  relies  increasingly  on  known  arrangements,  structural  specifications,  machinery  integration  and 
combat  systems  integration  for  specific  placement  of  weights  and  their  locations.  These  tasks  are  considered  weight 
accounting.  Another  task  is  hydrostatic  definition  of  the  hull.  Using  the  defined  hull  geometry  and  internal 
subdivision  (arrangements),  weight  engineers  generate  bonjean  curves,  floodable  length  curves,  and  other 
hydrostatic  displacement  tools.  Given  mass-moment  and  hydrostatic  properties,  static  stability  (stability  for  specific 
angles  of  heel)  is  assessed.  The  analysis  will  include  both  intact  and  damaged  conditions. 
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Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Deck  Height  Reduction  Study 

Machinery  Space  Tightness  Study 

Tank  Arrangements 

Boniean  Curves 

StaDilrty  Assessment 

Weight  &  Mass  Properties  Analysis 

""^pilrty  Specif lation  Input 

St;.,  tfy  Design  History  Input 

Weight  (3-.  5-Digit  A  Contract  Weights/Centers)  Estimates 

Contract  Design  Weight  Estimates 

Weight  Control  Program  Reports 

Weight  Specifications  Input 

Weight  Design  History  Inputs 

Construction  Margin  Report 

Weight  Database  (to  initialize  design) 

Ma'7'n  Allocations 

Fi&adable  Length 

Intact  and  Damaged  Stability  Analysis 

Volume  and  Displacement 

Master  Weight  Files  and  Data  Sheets 

Table  24  Weight  Engineering  Tasks 

Table  24  shows  the  progression  of  weight  engineering  tasks.  These  tasks  are  dominated  by  accounting  and 
analysis.  As  such,  weight  engineering  requires  input  from  all  design  specific  disciplines  as  well  as  requirements. 
Output  goes  to  hydrodynamics  (seakeeping  requires  righting  moment  data)  and  provides  first  order  analysis  to 
structures  (for  weight  distribution  curves),  arrangements,  and  systems  selections  (i.e.  weight  critical  loads  may  need 
to  be  moved  or  reduced.) 

4.6.3      Hydrodynamics-Resistance  and  Powering 

Resistance  and  powering  analyzes  the  link  between  requirements,  hull  geometry,  appendage  design,  and 
propulsion  plant  selection.  For  early  design,  resistance  is  empirically  based  (Taylor  Standard  Series  resistance.) 
Later  design  analysis  includes  model  testing  and  numerical  methods  (computational  fluid  dynamics  (CFD)  models.) 
As  discussed  previously  (see  Chapter  4.6.2),  the  analysis  methods  for  hydrodynamics  are  increasingly  integrated 
with  design  tools  to  provide  improved  design  iteration. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal    |       Production 

Powering/Resistance  Charactistencs 

1 

1 

1 

1 

1 

1 

1 

Speed-Power  Requirements  and  Report 

1 

1 

1 

1 

1 

1 

1 

Table  25  Hydrodynamics-Resistance  and  Powering  Tasks 

Table  25  shows  the  two  primary  resistance  analysis  task  types  (resistance  determination  and  report  of  results 
relative  to  requirements.)  Input  requirements  include  all  factors  effecting  resistance  and  speed  calculations 
(hullform,  appendages,  powering. )  For  the  current  naval  ship  design  process  model,  output  includes  hull  geometry, 
requirements,  appendage  design  and  propulsion  plant  design   Future  model  considerations  merge  many  of  the 
design  and  analysis  tasks  in  an  integrated  design  environment. 


4.3.4      Hydrodynamics-Seakeeping 

Seakeeping  is  the  measure  of  mission  performance  of  the  hullform.  and,  subsequently,  all  ship  systems, 
which  considers  ship  motion  in  the  operational  environment    Like  resistance,  it  represents  a  pure  analysis  discipline 
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that  is  being  increasingly  integrated  in  a  design  environment.  For  instance,  the  current  generation  of  HFDS  provides 
both  geometry  manipulation  and  seakeeping  analysis  with  programs  including:  Ship's  Motion  Program  (SMP), 
SWMP  and  SWISP  modules  for  SWATH  hullforms,  and  Seakeeping  Evaluation  Program  (SEP).  In  past  programs, 
seakeeping  was  rarely  addressed  in  early  design.  Tins  fact  is  apparent  in  the  tasking  from  Table  26.  However, 
seakeeping  is  increasingly  important  in  early  design  today  due  to  demanding  mission  requirements.  These 
requirements  include  a  greater  range  of  operating  environments  and  greater  seakeeping  demands  to  support  flight 
operations,  crew  and  payload  performance. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Seaway  Seakeeping  Performance  Assessment 

1 

1 

1 

1 

1 

1 

1 

Seakeeping  Report 

1 

1 

1 

1 

1 

Table  26  Hydrodynamics-Seakeeping  Tasks 

Seakeeping  requires  inputs  from  requirements,  hullform.  appendages  and  weight  properties,  as  well  as 
auxiliary  systems  (active  stabilization).  Outputs  from  seakeeping  go  to  programmatics,  hull  geometry  and 
appendage  sizing.  A  very  important  output  is  provided  to  structural  analysis.  Structural  analysis  uses  dynamic  sea 
loads  to  develop  the  structural  design  for  the  hull. 

4.6.5      Hydrodynamics-Maneuvering,  Control  and  Appendages 

Maneuvering,  control  and  appendages  are  the  remaining  system  considerations  relating  to  the  hull-water 
interface.  "(Maneuvering)  includes  starting,  steering  a  steady  course,  turning,  slowing,  stopping,  backing. .  "126 
These  tasks  include  the  design  and  assessment  of  appendages  including  rudders,  propellers,  and  passive  stabilizers. 
Specific  tasks  are  shown  in  Table  27  below.  These  tasks  are  determined  in  a  manner  similar  to  all  previous  design 
disciplines.  Additionally,  the  tasks  are  supplemented  by  the  an  excellent  summary  and  description  of  the  component 
tasks  found  m  Table  22  of  Principles  of  Naval  Architecture. 12" 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Propeller  Design  Report  and  Diagrams 

1 

Controllability  Assessment 

1 

Propeller  Trade-Off  Study 

Propeller  Specification  Input 

Propeller  Design  History  Input 

Control  and  Manuevenng  System  Design 

Hull  Equipment  &  Appendage  Design 

Maneuvering  and  Propeller  Soecificatjon  Inputs] 

Maneuvering  and  Propeller  Design  History  Inputs 

Hydro  Performance  Assessment 

Steering  Sear 

Table  27  Hydrodynamics-Maneuvering,  Control  and  Appendages  Tasks 

Data  interfaces  for  maneuvering  and  control  include  inputs  from  requirements,  hullform.  weight  distributions 
(for  turning  moments),  propulsion  plant  configuration  (for  propeller  sizing)  and  auxiliary  systems  (for  active  control 
systems.)  Output  goes  to  programmatics  and  performance,  producibility  (for  integration  of  appendages),  hull 


Crane,  Eda.  Landsburg,  "Controllability",  Principles  of  Naval  Architecture,  Society  of  Naval  Architects  and 


Marine  Engineers.  Jersev  City,  NJ,  1988,  chapter  IX. 
127  Ibid. 
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geometry  and  weights  (for  design  to  performance  iterations)  and  mechanical  systems  (for  adequate  sizing  of 
maneuvering  auxiliaries.) 

Note  that  propeller  design  is  included  with  maneuvering  design.  It  is  equally  acceptable  to  include  those 
tasks  under  propulsion  engineering. 

4.6.6      Structural  Engineering 

Structural  engineering  requires  the  design  of  hull  and  deckhouse  structure  to  resist  static  and  dynamic  loads 
on  the  hull.  Additionally,  structural  engineering  provides  for  support  and  isolation  of  installed  equipment  by  means 
of  foundations  and  force  absorbers.  Structural  engineering  requires  inputs  from  mission  requirements  and  assessed 
performance,  hull  configuration  and  loading,  and  installed  equipment  and  systems.  Structural  engineering  is  a 
combined  design  and  analysis  discipline.  Early  structural  design  uses  parametric  weight  distributions  and  historical 
wave  characteristics,  generates  anticipated  longitudinal  bending  stresses  from  these  characteristics,  and  iterates  this 
process  to  define  a  midship  section.  As  the  design  matures,  sections  are  generated  for  multiple  locations  in  the  hull. 
In  areas  of  higher  risk  (such  as  dynamic  loading  of  radars  on  masts),  finite  element  analysis  (FEA)  may  be  used. 
Later  in  the  process,  critical  spaces  (machinery  box,  magazines,  etc)  and  eventually  the  entire  ship  are  modeled  in 
FEA.  During  detailed  design,  structural  engineering  is  a  prime  focus  for  hull  design  as  the  complete  hull  geometry 
is  translated  into  structural  components  and  details.  Specific  implementation  of  structural  design  is  found  in 
Hughes1-8  and  Paullmg'"9.  Structural  output  is  used  by  programmatics  and  performance  assessment,  hull  geometry 
and  weights,  and  arrangements. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Define  Midship  Section  Structure 

Longitudinal  Strength  Assessment 

Payload  Structural  Assessment 

Shipyard  Producibihty  Practices 

Frame  Spacing 

Structural  Assessment 

Noise  &  Vibration  Analysis 

Design  Criteria 

Structural  SpecficaOon  Input 

Calculation  Report 

Structural  Arrangement 

Deck  Structural  Drawings 

Structural  (Scantling)  Drawings! 

Superstructure/Deckhouse  Structural  Drawipys 

Foundation  Design  &  Weight  Effective  Foundations 

Structural  Design  History  Input 

Bulknead  Structural  Drawings 

PSDM 

Table  28  Structural  Engineering  Tasks 

Table  28  shows  the  progression  of  structural  design  tasks.  Note  from  Chapter  8.5  that  over  the  course  of  the 
process  structural  productivity  must  increase  dramatically  (by  a  factor  of  200%)  to  accommodate  the  substantial 
increase  in  structural  design  effort  required  for  detailed  design. 


128 
129 


Hughes,  Ship  Structural  Design.  Society  of  Naval  Architects  and  Marine  Engineers,  Jersey  City.  NJ.  1988. 
Paulling.  '"Strength  of  Ships',  Principles  of  Naval  Architecture,  Society  of  Naval  Architects  and  Marine 
Engineers.  Jersey  City,  NJ,  1988,  chapter  IV. 
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4.6.7      Space  and  Arrangements 

Space  and  arrangements  are  the  means  by  which  the  hull  volume  is  allocated  and  optimized  In  pre-detailed 
design,  general  arrangements  identify  the  location,  physical  boundaries  and  function  of  each  space  in  the  ship. 
These  locations  are  utilized  for  weight  engineering,  survivability  assessment  (redundancy,  separation  and 
permeability),  and  manning  accommodations.  In  detailed  design,  the  concern  is  the  development  of  arrangements  of 
equipment  within  each  space  with  provision  for  required  access  to  every  component  on  the  ship.  Specifically,  the 
location  of  equipment  must  be  selected  to  satisfy  individual  component  performance  (location  of  radar  transmitters 
to  minimize  wave  guide  runs),  component  system  performance  (redundant  fire  pumps  separated  for  survivability) 
and  total  system  performance  (zonal  distribution  and  Collective  Protective  System  (CPS)  location.) 

The  outputs  from  arrangements  are  a  significant  input  to  programmatics  and  specifications.  In  particular, 
arrangement  drawings  and  Master  Equipment  Lists  (MEL)  are  an  important  component  of  configuration  baseline 
designs  that  complete  a  design  iteration.  As  a  design  element,  arrangements  are  utilized  by  performance  assessment 
and  weights  for  analysis.  Additionally,  hull  arrangements  must  converge  with  machinery  and  combat  systems 
arrangements.  (Note  that  machinery  systems  and  combat  systems  integration  include  specific  arrangement  tasks  due 
to  the  unique  requirements  of  those  disciplmes.) 

Table  29  shows  the  progression  of  space  and  arrangements  design  tasks.  Note  that  like  most  other  hull 
engineering  disciplines,  initial  tasks  are  based  on  parametric  or  empirical  design,  and  later  phases  rely  on  physical 
placement  of  components. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Arrangements 

Compartment  &  Access  (C&A)  List  &  Oufit  Drawings 

Area  Requirements 

Volume  Requirments 

HVAC,  CPS  and  Zonal  System  Arrangements 

Scecification  Control  Drawings  ISCD)  and  Specification  Inputs 

2D/3D  CAD  Model  Extraction 

Outfitting  Trade-Off  Studies 

Office  Space  Arrangement  Drawigns 

Medical  Arrangements  Drawings 

Outfitting  Specifications  Inputs 

Outfitting  Design  History  Inputs 

General  Arrangement  Drawings 

Habitability  Drawings 

CPS/Zona    Distr.bution  Sysrem  Zra/vr.gs 

Design  History  Input 

Functioinal  Drawings  -  Series  "K" 

Fabrication  Drawings  -  Series  "F" 

Installation  Drawings  -  Series  "1" 

Closure  List 

Table  29  Space  and  Arrangements  Tasks 

4.7       Machinery  Systems  Engineering 

Machinery  systems  engineering,  or  marine  engineering,  is  the  selection  and  integration  of  propulsion, 
electrical  and  support  systems.  Historically,  the  boundary  between  machinery  engineering  and  hull  engineering  is 
indistinct.  For  instance,  propeller  design  is  equally  important  to  both  disciplines    Likewise,  the  hull  form 
determines  the  propulsion  power  required  to  achieve  sustained  speed  levels  and  the  selected  propulsion  plant 
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determines  the  necessary  hull  form  to  support  the  plant.  These  interdependencies  are  reflected  in  the  DSM  for  naval 
ship  design.  Detailed  examples  of  machinery  tasks  and  interdependencies  can  be  found  in  Harrington130. 

Machinery  engineering  is  an  interdisciplinary  task  set  that  draws  on  engineering  disciplines  ranging  from 
mechanical  to  electrical  to  chemical  to  civil  engineering.  Specific  components  of  machinery  design  include: 

•  Propulsion  and  transmission  systems 

•  Electrical  generation  and  distribution 

•  Environmental,  fluid  and  support  auxiliary  systems 

•  Non-combat  related  auxiliary  systems  (deck,  handling  and  aviation  machinery) 

In  addition  to  component  selection  and  design,  the  machinery  plant  must  be  integrated  into  the  total  ship  and 
consider  the  total  impact  of  machinery  systems  on  fuel  capacity,  stack  length,  and  net  component  accounting 
(weight,  space  and  specification).  Machinery  system  discipline  productivity  and  task  levels  are  provided  in  Chapter 
8.5. 

4.7.1      Machinery  Systems  Design  and  Integration 

Machinery  system  design  is  the  integration  of  subordinate  mechanical  systems  in  the  ship  design.  For  early 
design  phases,  this  integration  provides  determination  of  total  fuel  requirements  (endurance  fuel  and  electrical 
generation  fuel)  and  machinery  arrangements.  Preliminary  machinery'  stack  length  and  plant  sizing  is  parametrically 
linked  to  ship  dimensions  (length,  beam,  hull  depth).  As  such,  ship  geometry  is  a  key  input  to  system  design. 
Additional  mputs  include  requirements,  performance  assessment,  weights  and  arrangements  (hull  and  topside),  hull 
performance  (resistance),  and  cost.  In  later  design  stages,  machinery  systems  become  better  defined  •with  specific 
components  selected  via  designation  in  the  Master  Equipment  List  (MEL)  and  other  parts  lists.  System  diagrams 
(cableways,  piping,  etc)  are  developed  and  refined  in  coordination  with  general  arrangements.  Machinery  control 
systems  are  developed  for  the  selected  mechanical  systems. 

The  output  from  systems  design  must  match  general  and  topside  arrangements,  weight  accounts,  performance 
estimates  and  programmatic  requirements.  Table  30  lists  the  progression  of  system  tasks.  Note  that  throughout 
mechanical  systems  design,  there  is  little  mention  of  mechanical  systems  development.  Rather,  it  is  assumed  that 
the  chosen  systems  are  mature  and  available  when  required  for  design  integration.  Future  iterations  of  the  design 
model  may  consider  specific  development  schedules  for  high  risk  technologies  (such  as  RACER  for  DDG-5 1  or 
Integrated  Propulsion  System  (IPS)  for  DD-21)  and  represent  those  dynamics  endogenously. 


30  Roy  Harrington.  Marine  Engineering.  Society  of  Naval  Architects  and  Marine  Engineers,  Jersev  City,  NJ,  1992. 
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Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Fuel  Requirements 

1 

Ship  System  Development 

1 

Machinery  Arrangement 

1 

Master  Equipment  List  (MEL) 

SSES  4  LBEF  &  SSEB  Support 

Machinery  Developments  Stuaies 

Macninerv  Controls 

Machinery  Control  Arrangements 

Outfit  and  Furshimng 

Material  Design  Standards 

System  Diagrams  with  associated  parts  list 

Interference  Checking 

Table  30  Machinery  Systems  Design  and  Integration 

4.7.2      Propulsion  Systems 

Propulsion  systems  engineering  is  the  selection  and  design  of  the  components  of  the  propulsion  train.  As 
discussed  previously,  these  efforts  do  not  require  the  specific  development  of  a  propulsion  engine  (such  as  a  specific 
gas  turbine  or  diesel  engine).  Rather,  the}'  provide  for  the  selection  of  engines,  determination  of  required  ship 
support  for  the  engines  and  development  of  power  train  elements  for  transmission  of  power.  It  is  possible  that 
selected  engine  systems  may  not  be  mature  during  the  initial  design  phases.  This  is  particularly  true  during  the 
development  of  nuclear  power  systems  or  new  technologies  (such  as  IPS.)  For  the  purposes  of  the  current  model, 
these  issues  are  ignored.  However,  such  issues  can  have  a  significant  cycle  time  impact  on  design.  Aside  from 
prime  movers,  many  unique  components  such  as  reduction  gear,  shafting  and  clutches,  may  be  specifically  designed 
within  the  context  of  the  naval  engineering  process.  Table  3 1  describes  many  of  the  specific  power  system  decisions 
that  must  be  made  during  this  tasking. 


Number  of  propulsors/shafts 

Direction  of  shaft  rotation 

Number  of  engine  rooms 

Number/Type  of  prime  movers 

Gear  Type/Location 

Exhaust  energy-  usage 

Power  transmission  method 

Fuel  Type 

Power  plant  location/geometry 

Power  plant  mounting 

K  factors 

Gear  Configurations 

Regeneration 

Thrust  reversing  method 

Control  type 

Inlet  type 

Exhaust  type 

Deicing  method 

Power  plant  locations 

Airborne  noise  control 

Vibration  control 

Table  31  Key  Propulsion  System  Trade-Off  Parameters131 

In  concept  design,  propulsion  plant  engineering  is  typically  restricted  to  selection  of  a  powering  concept  and 
determination  of  adequacy  of  the  concept  to  meet  performance  requirements    As  such,  inputs  must  include 
performance,  hull  resistance,  propulsor  concepts,  hull  arrangements  and  propulsion  support  systems.  Note  that 
propulsor  design  is  included  with  maneuvering  and  control.  It  would  be  equally  acceptable  to  include  propulsor 
design  with  the  propulsion  train  instead 


Myron  Ricketts.  Manual  for  Naval  Surface  Ship  Design  Technical  Practices.  Naval  Sea  Systems  Command. 
Washington  DC.  1980. 
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As  machinery  space,  weight  requirements,  and  fuel  needs  are  generated,  the  output  is  iterated  against 
performance,  maintenance  and  manning  concepts,  weights  and  hull  arrangements,  support  systems  and  cost.  Later 
iterations  of  the  propulsion  plant  further  refines  these  outputs  and  examines  transmission  concepts,  vibration,  stack 
design,  and  fluid  systems.  Final  design  stages  require  specific  arrangements  of  propulsion  components  and  support 
systems  and  management  of  production  preparations  (parts  and  components  ordering. )  The  complete  progression  of 
propulsion  system  tasking  is  found  in  Table  32. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition      I     Zonal 

Production 

Main  Propulsion  Concept 

1 

Main  Engine  Selection 

1 

Propulsion  System  Trade-Off  Study 

Fluid  System  Diagrams 

Endurance  Fuel  Requirements 

Propulsion  System  Design  Report  Input 

Propulsion  System  Specification  Input 

Shafting  Drawing 

Shafting  Vibration  Analysis 

Propulsion  System  Design  History  Input; 

Stack  Gas  Flow 

Table  32  Propulsion  Systems  Tasks 


4.7.3      Electrical  Systems 


Electrical  systems  design  follows  a  similar  progression  as  propulsion  plant  design.  During  early  design 
stages,  an  electrical  system  concept  is  developed  to  accommodate  performance  requirements,  support  systems  and 
combat  systems.  Electrical  requirements  are  initially  sized  based  on  manpower  levels,  hull  parameters  and  known 
power  requirements  for  selected  shipboard  systems.  Later  design  stages  examine  electrical  load  demand  and 
distribution.  Management  and  accounting  of  electrical  capacity  and  demand  becomes  increasingly  important  later  in 
design  as  system  growth  naturally  occurs. 

Electrical  system  growth  is  substantial  over  time.  The  first  naval  vessel  equipped  with  electrical  power  (the 
cruiser  USS  TRENTON  m  1883)  had  13.2  kW  of  power  capacity.  In  contrast,  the  DD  963  destroyer  (1970" s)  has 
6000  kW  capacity  and  the  DDG-51  (1980's)  has  7500  kW.  This  growth  in  electric  requirements  is  attributed  to  the 
following  technological  developments132: 

•  Weapons  development  including  ammunition  handling  and  electronic  warfare  sy  stems 

•  Electronic  command  control,  and  navigation  systems  with  high  powered  radar,  sonar,  and  electronic  data 
processing  equipment 

•  Habitability  improvements  including  electric  heating,  air  conditioning,  illumination,  and  refrigerated  storage 

•  Increased  use  of  electric  and  electrohydraulic  auxiliary  systems 

These  trends  require  some  increases  in  electrical  design  effort.  However,  the  greatest  trend  impacting  effort  is  the 
inclusion  of  Integrated  Power  Systems  (IPS  )  With  the  design  of  an  "all-electric"  ship,  this  category  of  design  could 
experience  significant  growth. 

For  the  current  model,  DDG-5 1  efforts  are  modeled  with  the  task  progression  shown  in  Table  33. 


Ibid.,  page  10-8. 
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Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Electric  Distribution  Design 

1 

Electric  Plant  Concept 

1 

Electrical  Line  Diagram 

Lighting  Analysis 

1 

Electrical  System  Specification  input 

Electrical  System  Trade-Off  Study 

Electrical  Load  Analysis 

Electrical  System  Design  History  Input 

Table  33  Electrical  Systems  Tasks 

4.7.4     Auxiliary  and  Support  Systems 

Auxiliary  systems  design  includes  those  system  required  to  support  ship  systems.  Specifically,  SWBS  group 
500  items  dominate  this  category-  of  design.  Auxiliary  systems  are  selected  based  on  inputs  from  requirements  and 
performance,  manning,  hull  geometry  (utilized  for  concept  level  sizing),  control  systems,  available  weight  and 
space,  propulsion  and  electrical  systems,  and  combat  systems.  The  selected  systems  provide  capabilities  for: 

•  Damage  Control. .  ventilation,  dewatering.  sensing.  CPS 

•  Environmental  Control . . .  heating,  ventilation,  air  conditioning,  refrigeration 

•  Fluid  Management ...  sea  water  supply,  fresh  water  generation  and  distribution,  air/gas  supply 

•  Pollution  Control. .  oily  waste  systems,  sewage  treatment,  solid  waste  disposal,  chemical/toxic  waste 
disposal 

As  a  closed  loop  design  process,  output  selections  are  provided  to  input  categories  and  costing  for  comparison  and 
iteration.  With  the  introduction  of  increased  computmg  capacrty  aboard  modern  warships,  this  category'  may  grow 
to  provide  adequate  environmental  conditioning.  For  the  baseline  case,  tasking  is  established  per  Table  34. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition      I     Zonal 

Production 

Distributive  System  and  Auxiliaries  Design 

1 

Fluid  System  Trade-Off  Studies 

, 

F;uid  System  Arrangement  Diagrams 

Fluid  System  Design  History  Input 

Fluid  System  Specifications  Input 

HVAC  Trade-Off  Studies 

HVAC  Diagrams  and  Arrangement  Drawings 

Fan  Room  Arrnagements 

HVAC  Design  History  Input 

HVAC  System  Report 

HVAC  Specification  Input! 

HVAC  System  Requirements  and  Criteria 

Steering  Systems 

Table  34  Auxiliary  and  Support  Systems  Tasks 


4.7.5      Deck,  Handling  and  Aviation  Support  Systems 

The  remaining  systems  are  those  components  assigned  to  SWBS  groups  570,  580  and  590.  Specifically, 
these  systems  are  required  to  support  conventional  ship  operations  (like  mooring,  anchoring,  towing,  etc),  underway 
replenishment  operations  (UNREP)  and  aviation  operations.  These  systems  are  less  dependent  on  input  then 
previous  mechanical  systems.  Specifically,  input  is  required  from  performance  and  requirements,  weight  and  space 
allocations  and  electrical  and  support  system  budgets.  The  design  output  is  returned  to  the  input  disciplines  and 
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cost,  manning  and  maintenance.  The  progression  of  task  elements  is  provided  in  Table  35.  For  future  design 
models,  these  tasks  will  input  to  topside  design  because  of  their  importance  of  reducing  ship  signatures. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Deck/UNREF  Systems 

1 

1 

Deck  System  Trade-Off  Studies 

1 

Anchor  Mooring  &  Towing  Drawings 

1 

Deck  Systems  Design  History  noire 

1 

Deck  Systems  Specification  Input 

1 

Aircraft  Support  System 

1 

Boat  Handling  and  Stowage  Arrangements  and  Drawings 

1 

Table  35  Deck,  Handling  and  Aviation  Support  Systems  Tasks 

4.8       Mission  Systems  Engineering 

Mission  systems  engineering,  also  known  as  combat  systems  engineering,  is  the  selection  and  integration  of 
those  combat  pay  loads  necessary  to  meet  the  mission  requirements  of  the  surface  combatant.  The  selected  systems 
must  be  fully  integrated  into  the  arrangements  of  the  combatant.  Recall  the  combat  systems  trends  discussed  in 
Chapter  1.1.3  and  Figure  12.  Older  combat  systems  (gun  systems  and  visual  guidance)  were  weight  critical,  dense, 
and  placed  low  in  the  hull.  The  resulting  ship  had  large  displacement,  but  smaller  beam  for  the  desired  stability' 
requirements.  The  combat  system  provided  a  reaction  time  suitable  for  the  threats  of  that  time.  As  threat 
capabilities  advanced,  combat  systems  matured  with  the  transition  from  guns  to  missiles  and  visual  to  radar 
guidance.  Consequently,  the  ship  integration  issues  changed.  Modern  warships  must  accommodate  volume  and 
height  critical  systems  to  achieve  necessary  performance.  The  result  was  initially  lower  displacement  in  ships  like 
the  DD-963  with  less  dense,  moderately  high  systems.  As  response  time  and  multi-mission  performance  demanded 
increased  sensor  height  and  greater  payload  volume,  displacement  and  beam  growth  was  necessary  to  provide 
adequate  stability  for  highly  placed  radar  systems. 

Note  that  combat  systems  engineering  in  this  context  is  not  the  design  of  combat  systems  themselves.  The 
Fields  of  combat  systems  design  (detect  to  engage  chains)  and  testing  (probability  of  detect  and  kill,  reliability,  etc) 
represent  product  development  processes  unto  themselves.  Although  these  systems  are  becoming  increasing 
integrated  into  the  ship  development  process  (such  as  the  Aegis  Weapon  System  and  CG-47).  removing  weapon 
systems  development  from  the  boundaries  of  the  model  is  necessary  to  allow  examination  of  naval  ship  design. 
Future  models  may  endogenously  include  major  weapon  systems  development.  However,  these  systems  should 
only  be  included  if  the  weapon  systems  development  schedule  are  shown  to  dynamically  influence  the  ship  design 
process. 

Baseline  productivity  and  task  levels  for  the  DDG-5 1  program  combat  systems  integration  (independent  of 
combat  systems  development)  are  provided  in  Chapter  8.5. 

4.8.1      Mission  Systems  Selection,  Design  and  integration 

Mission  systems  include  those  payloads  required  for  the  combatant  to  satisfy  specific  warfare  requirements  of 
the  ORE)   These  systems  can  include  communications  (both  internal  and  external),  sensors,  weapons  and  control.  It 
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does  not  include  the  development  process  of  those  systems,  but  rather  assumes  systems  are  available  and  must  be 
integrated  with  the  ship  design.  Note  that  there  has  been  tremendous  criticism  over  the  years  concerning  the 
apparent  disconnect  between  the  ship  design  community  and  weapon  systems  development  community.133 
Specifically,  lack  of  coordination  between  the  two  communities  has  lead  to  tremendous  schedule  fluctuations. 
Consider  Figure  33.  The  figure  shows  the  months  required  to  launch  each  vessel  in  the  class  for  the  CG-47  Aegis 
Cruiser.  Note  that  the  class  experienced  4  major  combat  system  baseline  changes  over  the  course  of  the  program. 
This  can  be  correlated  to  the  four  oscillations  in  delivery  schedule.  This  trend  dominates  actual  hours  of  effort 
which  reflect  the  expected  learning  curve.  Thus,  schedule  delays  from  late  GFE/GFI/GFM  effectively  negate  the 
benefits  of  production  efficiencies.  This  trend  is  changing  n  current  programs  like  DD-2 1  and  should  be  considered 
in  future  model  designs. 

Input  requirements  for  mission  systems  design  include  performance  and  requirements,  weight  and  space 
budgets,  support  system  capacity  and  topside  arrangement  issues.  Output  is  iterated  with  the  same  disciplines  as 
well  as  structural  design  and  cost.  The  complete  progression  of  design  tasks  is  shown  in  Table  36. 
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Figure  33  CG-47  Class  Delivery  Schedules  and  Production  Efforts1 


133  Tibbitts  and  Keane.  "Naval  Ship  Design  in  the  21st  Century',  Society  of  Naval  Architects  and  Marine  Engineers. 
Jersey  City.  NJ,  1993. 
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Mike  Jeffers.  Interview  at  Naval  Surface  Warfare  Center  Carderock  Division,  Bethesda.  MD.  November  12. 


1997. 
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Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Combat  System  Integration  Manag?ment 

1 

IC/havigauon  Integration  and  Diagrams 

1 

Exterior  Comms  (5PAWAR-NAVELEX)  System  4  Antenna  Integration 

1 

Shipboard  Data  Multiplex  System  (SDMS) 

Combat  Systems  Design  Support,  Testing,  IVCS  &  :SMS 

Command  and  Control  Space  Arrangements 

Mission  Systems  Design  History  Input 

Mission  Systems  Specification  input 

Armament  and  Weapon  Systems  Integration 

IC  Matrix 

Table  36  Mission  Systems  Selection,  Design  and  Integration  Tasks 

4.8.2      Topside  Design  and  Integration 

With  the  introduction  of  modern  weapon  systems  (missiles,  communications,  and  radars)  has  come  increased 
need  to  manage  topside  design.  Specifically,  modern  combat  systems  generate  unique  integration  problems  due  to 
azimuthal  coverage  requirements,  electromagnetic  interference  (EMI),  signature  reductions  including  radar  cross 
section  (RCS)  and  Infrared  (IR),  and  aperture  height  requirements.  These  needs  require  detailed  accounting  and 
modeling  of  system  interactions  and  allocation  of  valuable  topside  real  estate   At  the  concept  level,  integration  is 
typically  limited  to  basic  arrangement  diagrams.  The  requirements  for  inputs  include  mission  systems  selected, 
distance  and  capacity  of  supporting  systems,  arrangements  of  non-combat  system  topside  elements  (deck,  handling 
and  aviation  systems),  and  performance  requirements.  Of  particular  concern  are  the  mass  moment  and  subsequent 
stability  of  the  ship.  As  topside  systems  demand  increasing  heights  and  weights,  the  impact  on  hydrostatic 
performance  is  significant.  As  discussed  previously,  these  impacts  are  proving  evolutionary  in  combatant  ship 
design. 

In  later  stages  of  topside  design,  specific  analysis  of  EMI  impacts,  coverage,  source-victim  effects,  and 
combat  system  performance  must  be  addressed  to  optimize  topside  arrangements.  Like  hull  engineering  (HFDS). 
the  demands  of  technology  coupled  with  the  current  trend  to  integrate  design  and  analysis  has  resulted  in  the 
creation  of  software  suites  for  topside  engineering.  Systems  such  as  LEAPS  and  Electromagnetic  Engineering 
(EMENG)  are  providing  topside  engineers  with  the  ability  to  analyze  greater  combat  systems  detail  much  earlier  in 
the  design  process.  Such  efforts  are  necessary  if  modern  warships  are  to  meet  current  requirement  demands  for 
passive  and  active  defense.  Later  variations  of  the  design  process  model  may  be  modified  to  reflect  the  increased 
concept  design  effort  necessary  for  programs  like  the  DD-2 1 .  The  baseline  tasking  progression  is  shown  in  Table 
37. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition       I     Zonal 

Production 

Topside  and  Combat  Systems  Integration 

1 

1 

Topside  &  Combat  Systems  Arrangements 

1 

1 

Topside  Arrangement  Drawings 

1 

EMI  Analysis 

1 

Arcs  of  Fire  4  BAM  Analysis 

1 

Table  31  Topside  Design  and  Integration  Tasks 

Output  from  topside  engineering  is  iterated  with  mission  systems  selection,  support  systems,  arrangements, 
weight,  performance,  maintenance  and  manning,  and  programmatics. 
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4.9       Cost  Engineering 

A  final  component  of  the  total  systems  engineering  process,  along  with  performance  assessment  and 
schedule,  is  cost.  In  this  context,  cost  represents  all  aspects  of  total  ownership  cost  (TOC)  for  the  developing 
system.  In  the  context  of  the  naval  ship  design  process,  cost  engineering  represents  that  component  of  ship  design 
by  which  the  acquisition  and  life  cycle  cost  of  the  developing  design  is  assessed  against  program  cost  constraints. 
As  such,  it  does  not  include  the  expenditures  of  funds  for  R&D  or  current  spending  on  the  design  process  (those 
current  costs  are  modeled  explicitly,  see  Chapter  5.5).  Cost  engineering  addresses  the  specific  cost  dynamics 
discussed  previously  in  Chapters  1.1.3  and  2.3.  These  behaviors  demonstrate  that  cost  is  and  will  continue  to  be  the 
primary  driver  in  naval  ship  design  and  acquisition.  DDG-5 1  cost  constraints  explicitly  operated  as  a  closed  loop 
feedback  control  process. .  indicative  of  a  dynamic  control  process. 13:>  Exceeding  cost  estimates  resulted  in 
significant  design  effort  and  design  change  (see  Figure  16.)  This  trend  is  severely  criticized  in  light  of  questionable 
cost  estimate  accuracy.  The  result  is  increased  demand  for  robust  costing  methods  such  as  Product-Oriented  Design 
and  Construction  (PODAC)  cost  models  and  access  to  costing  models  such  as  ACEIT  at  the  engineering  level. 
These  issues  are  beyond  the  scope  of  this  work.  However,  the  nnpacts  of  these  methodologies  provide  more  tasks  in 
early  design  off-set  by  decreased  iterations  generated  from  cost.  The  result  is  a  relatively  constant  productivity  rate 
for  costing  and  decreased  feedback  late  in  the  design  process  (after  concept  design. ) 

Chapter  8.5  contains  productivity  and  tasking  baseline  data  for  the  DDG-5 1  program.  Specific  types  of  cost 
estimates  and  their  relationships  to  the  design  process  are  provided  below. 

4.9.1      Cost  Estimates  and  Analysis 

Cost  estimates  and  analysis  are  the  aggregates  of  all  engineering  cost  studies  for  the  naval  ship  design 
process.  These  estimates  represent  specific  types  of  cost  estimates  required  by  DoD  doctrine  at  each  milestone  and 
consequentially,  each  design  phase.  Note  that  design  process  budgeting  considers  a  separate  process  within  the 
naval  ship  design  model.  Budgeting  for  the  design  is  accomplished  by  the  Planning.  Programming  and  Budgeting 
System  (PPBS)  and  is  explicitly  modeled  (see  Chapter  5.5). 

Cost  estimates  are  designated  by  classes,  which  correspond  to  a  given  phase  of  the  design  process.136  The 
least  detailed  classes  of  cost  estimates  are  Class  E  and  F.  They  are  based  on  1 -digit  weight  based  cost  models  such 
as  parametric  cost  estimating  relationships  (CERs).  If  specific  costs  for  components  (propulsion  systems  or  combat 
systems)  are  known,  they  are  included.  The  ACEIT  model  uses  CERs.  Class  E  and  F  estimates  provide  order  of 
magnitude  estimation  for  concept  design.  At  the  end  of  concept  design,  a  Class  D  estimate  may  be  provided.  Class 
D  estimates  provide  refined  weight  based  cost  and  establish  the  basis  for  design-to-cost  estimates  for  contracting. 
During  preliminary  design.  Class  C  estimates  are  provided.  Class  C  estimates  are  budget  quality  estimates,  but  are 
still  based  on  weight  based  parametrics.  However,  these  estimates  increasingly  incorporate  engineering  analysis  of 
design  characteristics.  For  instance,  with  the  introduction  of  PODAC  costing  methods.  Class  C  estimates  should 


135  Hope  and  Stortz.  "Warships  and  Cost  Constraints".  Naval  Engineers  Journal.  March  1986.  page  41-43. 
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begin  to  reflect  direct  producibility  cost  impacts  beyond  simple  shaping  functions  which  are  often  applied  to 
parametrically  based  costs.  Additionally,  life  cycle  cost  models  are  being  developed  to  provide  cost  analysis  of 
manning,  ILS,  and  operational  impacts  as  well  as  development  and  production.  For  example,  the  ACEIT  cost  model 
is  modified  to  provide  differentiation  of  varying  production  rates  and  multi-year  contracts.  Class  B  estimates  are 
provided  during  contract  design.  These  estimates  establish  the  cost  ceiling  for  the  acquisition  (again  by  design-to- 
cost  methodology  and  typically,  weight  based  costing  models)  by  which  contract  bids  are  judged.  Class  B  estimates 
are  often  referred  to  as  Bid  Evaluation  Cost  Estimates.  Detailed  cost  estimates,  or  post-budget  costs,  are  realized 
costs  associated  with  material  acquisition  and  compared  to  bid  and  contract  cost  estimates. 

There  is  an  ever-increasing  body  of  cost  estimating  tools,  cost  trade-off  studies  and  cost-risk  tasking.  For 
modeling  purposes,  the  growth  of  cost  tasking  is  ignored  relative  to  the  baseline  program.  Baseline  tasks  (DDG-51) 
are  shown  below  in  Table  38.  Inputs  for  developing  these  tasks  are  primarily  weight  based.  Therefore,  cost  tasking 
relies  on  design  characteristics  (hull,  weights,  structures,  machinery  and  combat  systems)  that  are  related  to  SWBS 
groups.  For  life  cycle  cost  estimates,  manning,  ILS,  and  producibility  are  also  incorporated  The  output  from 
costing  is  provided  to  programmatics  as  well  as  first  order  changes  to  those  design  characteristics  that  exceed  cost 
thresholds  for  cost  sensitivity  such  as  structural  weight  and  auxiliary  systems. 


Task  Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Independent  Cost  Estimate  &  Unit  Cost  Report  (IC&UCR) 

1 

1 

Class  D/E'F  Cost  Estimate 

1 

1 

Program  Life-Cycle  Cost  Estimate 

1 

1 

Class  C  Cost  Estimate 

i 

Weight  &  Cost  Engineering 

Class  B  Cost  Esomate 

1 

Table  38  Cost  Estimates  and  AnaJvsis  Tasks 


Myron  Ricketls,  Manual  for  Naval  Surface  Ship  Design  Technical  Practices,  Naval  Sea  Systems  Command. 
Washington  DC,  1980,  section  14. 
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5       Process  Model  Sectors 

The  following  sections  provide  brief  descriptions  of  the  primary  components  of  the  naval  ship  design  model. 
For  specific  model  elements  (equations  and  values)  refer  to  the  Vcnsim  modeling  code  provided  in  chapter  8.7.  A 
graphic  representation  of  the  design  process  model  is  shown  in  Figure  35. 

5.1       Process  Sector 

The  basic  structure  for  all  system  dynamics  product  development  models  is  the  rework  (or  work 
accomplishment)  structure.  The  structure  may  have  several  forms  such  as  that  shown  in  Figure  22  or  Figure  34. 
The  structure  demonstrates  that  from  an  initial  pool  of  work  to  do  (TBD),  work  is  accomplished  at  some  rate.  Based 
on  a  dynamically  determined  level  of  quality,  some  work  is  accomplished  correctly  and  some  requires  rework.  The 
incorrect  tasks  remain  in  error  until  discovered  through  a  QA  process  and  reassigned  as  work  to  do. 
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Figure  34  Work  Accomplishment  Structure 

Several  specific  project  models  were  examined  for  applicability  to  the  naval  ship  design  process  problem. 
These  previously  developed  models  include  the  Ingalls  Litigation  Model  (Cooper.  1980),  Program  Management 
Modeling  System  (PMMS)  (Pugh-Roberts  Associates.  1997).  Software  Project  Model  (Abdel-Hamid  and  Madnick 
1991)  and  Concurrent  Development  Model  (Ford  and  Sterman,  1997).  Each  model  was  studied  for  behavior  and 
policy  elements  applicable  to  naval  ship  design.  Selected  components  of  those  models  form  the  structural  engine  for 
the  naval  ship  process  model.  Figure  36  shows  this  structure. 
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Figure  36  Naval  Ship  Design  Process  Model  Work  Accomplishment  Structure 

5.1.1  Primary  Work  Flow 

The  stmcture  in  Figure  36  demonstrates  an  operational  view  of  the  design  process.  At  the  beginning  of  the 
current  design  phase,  some  known  level  of  baseline  tasking  is  released  as  tasks  to  be  done  (TBD).  Those  tasks  are 
assigned  to  the  engineering  staff  and  become  work  in  progress  (WIP).  Based  on  an  accomplishment  rate  (Comp 
Rate)  tasks  are  completed.  The  completed  tasks  either  require  iteration  (due  to  internal  error  discovery  or  design 
spiral  relationships)  or  review.  The  reviewed  tasks  either  require  iteration  (review  error  discovery)  or  release  as 
approved  tasks.  Approved  tasks  are  considered  completed  and  not  subject  to  further  action.  Note  that  this 
assumption  may  fail  to  fully  capture  rescope  impacts  which  occur  very  late  (high  levels  of  approved  tasks)  in  the 
design  phase.  The  iterated  tasks  represent  rework  and  are  accumulated  for  coordination  (Coord  Rate).  Based  on  a 
coordination  rate,  the  rework  is  released  back  to  the  work  flow  as  WIP.  The  structure  also  reflects  the  potential  for 
scope  growth  (rescope  rate).  Rescope  tasking  enters  the  flow  through  TBD  for  assignment 

5.1.2  Review  and  Approval  Factors 

A  key  structure  in  the  process  is  the  inclusion  of  review  and  approval  For  naval  ship  design  projects,  such 
review  is  required  by  law.  However,  the  extent  and  duration  is  subject  to  interpretation.  Review  is  considered  an 
internal  activity  performed  at  the  program  level  and  below.  Primary  participants  are  program  management  staff. 
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activity  staff  (both  NAVSEA  and  contractors)  and  interested  parties.  Approval  is  the  acceptance  of  the  design  by 
external  forces.  Approval  must  include  those  organizations  required  to  participate  by  law  (DoN.  DoD  and  program 
managers)  and  interested  parties.  As  discussed  in  Chapters  1.1  and  4.4,  the  review  process  is  a  source  of  cycle  time 
delay  and  growth.  The  required  products  for  design  review  and  the  large  numbers  of  review  and  approval  levels 
were  a  primary  concern  to  DAC  study  participants.  During  the  DAC.  data  was  gathered  that  described  average 
approval  and  review  periods  for  over  45  DoN  projects.  Additionally,  limited  data  on  CG-47  and  DDG-5 1  approval 
and  review  periods  was  available.  These  values  are  shown  in  Chapter  8.5.  Interviews  (see  Chapter  8.2)  with 
process  participants  indicated  that  review  and  approval  times  (not  error  correction)  are  the  primary  sources  of 
generated  delays.  As  such,  the  model  incorporates  these  delays  directly  as  approval  and  review  periods  through  first 
order  control. 

5.1.3      Error  Generation  and  Detection 

Errors  form  a  significant  source  of  feedback  in  a  development  process.  As  discussed  in  Chapter  3.1, 
generated  errors  (regardless  of  a  specific  cause)  must  be  discovered  and  reassigned  to  correct.  In  system  dynamics 
models,  error  generation  is  a  dynamic  event  that  may  be  coupled  to  forces  such  as  schedule  pressures,  workforce 
experience,  and  fraction  of  job  complete.  QA  efforts  are  also  dynamic  with  improved  QA  productivity  occurring  as 
the  project  approaches  completion  Functional  forms  for  error  and  QA  efforts  relative  to  those  forces  can  be  found  in 
Abdel-Hamid  and  Madnick,  1 99 1 137. 
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Figure  37  Naval  Ship  Design  Process  Model  Error  Sector 

Figure  37  shows  the  error  sector  for  the  naval  ship  design  model.  Two  dynamic  modifiers  were  chosen  for 
error  generation  and  discovery.  First,  errors  are  more  likely  in  earlier  design  phases  than  later.  As  such,  the  chosen 
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error  fractions  (as  a  fraction  of  total  tasks  completed)  reflects  decreasing  rates  as  the  project  approaches  detailed 
design.  Additionally,  as  the  total  error  discovered  increases,  the  fraction  of  new  error  decreases.  In  error  discovery, 
these  factors  work  in  reverse:  as  the  project  matures  QA  improves  and  as  total  errors  increase  QA  effectiveness 
increases.  The  selection  of  baseline  error  rates  (20%  in  concept  design  to  10%  in  detailed  design)  were  based  on 
interviews  with  personnel  at  both  NAVSEA  and  Bath  Iron  Works  (BIW)  (see  Chapter  8.2). 

5.1.4      Design  Feedback 

The  one  structure  of  the  naval  ship  design  model  not  found  in  other  system  dynamics  models  is  that  of  the 
design  feedback  loop.  This  dynamic  reflects  the  interrelationship  of  the  23  specific  design  disciplines  participating 
concurrently  in  the  design  process.  Using  the  DSM  developed  in  Chapter  4.3,  tasks  are  reworked  at  a  rate  consistent 
with  the  following  criteria: 

•  As  task  A  is  completed,  a  fraction  of  that  task  is  "undone"  by  concurrent  work  in  tasks  to  which  task  A  is 
dependent 

•  Task  A  is  "undone"  at  a  rate  not  to  exceed  its  own  completion  rate  or 

•  "Undone"  at  the  fastest  rate  of  all  its  input  tasks. 

The  feedback  fraction  represents  the  fraction  of  tasking  that  are  "undone"  by  process  concurrence.  The  value  may 
be  though  of  as  either  the  average  allowable  margin  for  change  at  the  given  design  phase  or  as  1  minus  the  fraction 
of  performance  and  cost  lock-in  (see  Figure  5.)  Those  tasks  that  are  sent  to  iteration  must  be  coordinated  to 
determine  what  data  has  changed  and  what  errors  must  be  corrected.  The  coordination  rate  is  (like  the  approval  and 
review  dynamic)  a  first  order  control  through  TBCoord  and  the  average  coordinate  period. 

5.2       Scheduling  Sector 
5.2.1      Desired  Schedule 

The  concept  of  schedule  encompasses  the  desired  cycle  time  for  the  design  project.  It  represents  one  of  the 
three  primary  trade-offs  of  the  project  (Section  1.1.)  It  is  by  the  selection  of  schedule  that  all  other  model  variables 
are  estimated  and  controlled.  For  instance,  fixing  schedules  and  design  products  produces  a  required  manning  level 
and  the  subsequent  cost  of  those  personnel.  Schedule  is  not  fixed  over  the  life  of  the  project.  Consider  Table  39. 
The  desired  schedule  for  contract  award  was  allowed  to  slip  many  times  over  the  course  of  the  DDG-5 1  project  and 
at  increasing  rates  as  the  estimate  date  and  the  desired  date  converged.  Table  40  further  demonstrates  the  sliding  of 
schedule  dates  over  the  course  of  the  project. 
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Date  of  Estimate 

March  15 

19831J8 

June  1.  1984139 

December  9.  1 99 1 ' 4U 

Desired  Schedule 

December  15.  1984 

January  10, 

1985 

April  2.  1985 

Change  from  Previous  Estimate 

- 

1  month 

3  months 

Table  39  Schedule  Estimates  for  DDG-51  Contract  Award141 

Date  of  Estimate 

4/15/83 

6/1/84 

6/1/87 

12/9/91 

Concept  Design  Start 

8/1/78 

Senior  Review 

2/1/82 

Command  Review 

12/15/82 

Concept  Design  End 

3/31/82 

Preliminary  Design  Start 

3/31/82 

SCIB 

10/1/82 

Senior  Review 

12/1/82 

Command  Review 

12/15/82 

Preliminary  Design  End 

5/13/83 

Contract  Design  Start 

5/14/83 

DSARC 

8/26/83 

Baseline  Freeze 

9/2/83 

Invoke  Configuration  Control 

7/22/83 

9/30/83 

Contract  Design  Circulation 

12/5/83 

3/28/84 

3/28/84 

Senior  Review 

12/15/83 

5/15/84 

5/15/84 

Command  Review 

1/15/84 

5/29/84 

5/29/84 

Contract  Design  Reading  Session 

3/5/84 

6/1/84 

6/1 5/84 

Contract  Design  Signature 

5/25/84 

6/9/84 

6/29/84 

Contract  Design  End 

3/1/85 

Contract  Award 

12/15/84 

1/1/85 

4/2/85 

Lead  Ship  Launch 

5/1/88 

9/16/89 

Lead  Ship  Delivery 

9/1/89 

7/1/89 

4/29/91 

Table  40  Key  Program  Dates  and  Schedule  Shifts142 

To  model  this  behavior,  the  following  generic  elements  are  applicable  (Figure  38.)  From  an  equilibrium 
condition  (schedule  gap  is  zero),  assume  a  perturbation  occurs  and  estimated  completion  exceeds  scheduled  date. 
Initially,  gap  increases,  pressure  to  mcrease  workforce  levels  increases,  workforce  increases,  accomplishment  rate 
increases,  project  duration  decreases,  estimated  date  decreases  and  gap  decreases ...  a  balancing  system  through 
estimated  completion  date.  Simultaneously,  as  the  estimated  date  exceeds  the  desired  date,  the  desired  date  updates 
to  match  estimates.  The  time  to  change  schedule  represents  the  average  time  required  to  absorb  half  the  schedule 
gap.  As  the  desired  schedule  increases,  the  gap  decreases,  pressure  to  increase  manpower  decreases,  manpower 
decreases  and,  ultimately,  the  estimated  date  slides  further. .  a  reinforcing  system  through  desired  completion  date. 


CAPT  J.J.  Fee  (USN).  US  Navy  letter  50C/JJF  Serial  5032-042.  April  15.  1983. 


138 

139  Naval  Sea  Systems  Command.  Ship  Design  Proiect  Histories:  Volume  II  1980-1989.  estimated  edit  date  June 

1984.  page  2.8-5. 

40  Joe  Daley.  PMS-400B  Program  Office.  Washington  DC,  correspondence  dated  December  9.  1991. 


See  footnotes  138,  139.  140. 
Ibid. 
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Based  on  the  observed  schedule  (Table  40).  the  initial  values  for  the  baseline  design  model  are  established 
(Table  41.)  The  adjustment  time,  as  input  to  an  exponential  decay  function,  may  be  approximated  as  follow: 

^.         TimeToCloseGap 
AdjustmentTiine=  = 

3 
The  Time  to  Close  Gap  is  the  time  to  observed  phase  end.  Thus,  an  Adjustment  Time  of  12  months  is  consistent 
with  the  observed  results. 


<Time~ 
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schedule 
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Scheduled 
completion  date 
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Figure  38  Generic  Schedule  Model 
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Design  Phase 

Concept 

Preliminary 

Contract 

Lead  Ship 

Manufacturing 

Initial  Schedule  Projection 
(months  from  start) 

36 

48 

60 

72 

78 

Table  41  DDG-51  Design  Process  Model  Desired  Schedule  Initial  Values 

The  generic  structure  is  reflected  in  the  naval  ship  design  process  model  as  the  schedule  sector  (Figure  39). 
Like  the  generic  structure,  tasks  remaining  are  compared  to  the  available  manpower  and  nominal  design  rate  to 
determine  a  projected  completion  date.  This  date  is  compared  to  the  desired  date  to  generate  a  gap.  Based  on  the 
gap.  adjustments  are  made  to  manpower,  productivity  and  overtime  (see  Figure  35  to  observe  those  feedback  links). 

One  slight  modification  is  noteworthy.  Instead  of  measuring  progress  by  what  remains,  naval  ship  project 
managers  measure  progress  by  what  is  done.  Specifically,  the  perceived  tasks  completed  is  a  function  of  completed 
tasks  (completed,  reviewed  and  approved).  The  tasks  to  be  done  are  then  generated  by  comparing  completed  tasks 
to  the  expected  total  tasks  for  the  current  phase:  initial  tasks  times  the  percent  phase  complete  desired.  Percent 
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Jim  Hines.  "Molecules  of  Structure  Version  1.3",  LeapTec  and  Ventana  Systems.  1997,  page  85-86. 
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phase  complete  desired  is  the  fraction  of  total  tasks  that  must  be  completed  to  allow  designers  to  proceed  to  the  next 
iteration.  This  alternate  structure  can  be  found  in  other  project  management  models 
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Figure  39  Naval  Ship  Design  Process  Model  Schedule  Sector 

5.2.2      Phase,  Review  and  Approval  Initiation 

Due  to  the  inclusion  of  multiple  design  phases  (concept  design,  preliminary  design,  contract  design,  lead  ship 
detailed  design  and  manufacturing  engineering  design)  and  multiple  stages  within  a  single  phase  (tasks  in  progress, 
tasks  under  review,  and  tasks  under  approval),  it  is  necessary  to  establish  a  structure  to  initiate  subsequent  sequences 
and  close  previous  ones.  The  phase  initiation  structure  is  shown  in  Figure  40.  Based  on  the  comparison  of  approved 
tasks  to  total  tasks  for  the  phase,  the  percentage  complete  is  generated.  That  percentage  is  compare  to  the  required 
percentage  necessary  to  proceed  to  the  next  phase    When  the  current  phase  percentage  is  satisfied,  a  Boolean 
operator  (Current  Phase)  is  set  to  1  for  the  next  phase  to  start  the  release  of  new  tasks.  Simultaneously.  Current 
Phase  is  set  to  0  for  the  phase  being  completed.  This  prevents  the  release  of  further  tasks  and  resources  to  the 
completed  phase.  A  parallel  structure  is  present  for  release  of  tasks  to  review  (completed  tasks  become  available  for 
review)  and  approval  (reviewed  tasks  become  available  for  approval).  However,  unlike  the  Current  Phase  variable, 
approval  and  review  operators  do  not  stop  previous  segments  from  contmuing. 
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Figure  40  Naval  Ship  Design  Process  Model  Phase  Initiation  Structure 


5.3       Productivity  Sector 

Productivity  is  the  measure  of  the  effective  rate  by  which  available  manpower  is  able  to  complete  assigned 
tasking.  Figure  41  shows  an  example  of  a  generic  productivity  calculation.  This  structure  shows  how  a  nominal 
productivity  level  (normal  productivity)  is  influenced  by  factors  such  as  fatigue,  schedule  pressure  (or  schedule  gap) 
and  work  adequacy  (or  fraction  of  design  change).  Productivity  as  shown  here  is  measured  as  the  number  of  tasks 
completed  per  person  per  unit  time. 

Productivity  is  a  very  difficult  quantity  to  measure.  This  is  true  because  observed  productivity  represents  the 

work  rate  after  the  modifications  by  dynamic  influences  (fatigue,  schedule  pressure,  etc)    As  such,  nominal 

productivity  represents  a  fraction  very  different  than  that  which  is  observed.  Consider  the  naval  ship  design  process 

model  productivity  functions  (Figure  42).  Like  the  generic  structure,  numerous  dynamic  influences  are  included: 

fatigue,  organizational  size,  and  schedule  gap.  The  average  design  rate  is  included  to  represent  the  nominal 

productivity  level.  This  value  actually  represents  the  observed  rate  for  a  given  project  and  is  calculated  as: 

.             _.         _                      TotalTasksPerDesisnDisciplinePerPhase 
AverageUesignKate  = — 

TotalPersonnelPerDisciplinePerPhase     PhaseDuration 

This  rate  would  represent  the  value  used  by  program  managers  to  assess  progress  or  model  the  process  in 

scheduling  programs  (CPM/PERT  models).  For  the  DDG-5 1 .  the  average  design  rates  are  calculated  and  shown  in 

Chapter  8.5.  However  for  the  process  model,  this  rate  must  be  adjusted  to  reflect  the  actual  baseline  rate  absent  of 

dynamic  influences.  The  observed  rate  is  multiplied  by  an  adjustment  (Adjust  Rate)  in  the  naval  ship  model  to 

provide  calibration  of  the  observed  rate  in  order  to  reflect  the  nominal  rate  of  productivity. 
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Figure  41  Generic  Productivity  Structure 
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Figure  42  Naval  Ship  Design  Process  Model  Productivity  Sector 

With  the  effective  productivity  rate  established  (Net  Productivity  Rate),  it  is  multiplied  by  the  effective 
personnel  level  to  provide  a  completion  rate  (Comp  Rate)  by  which  the  pool  of  WIP  is  completed.  Note  that  the 
Comp  Rate  has  a  ceiling  rate  (maximum  rate  of  completion)  provided  by  the  first  order  feedback  through  WIP  and  a 
minimum  completion  time  for  a  single  design  task.  That  minimum  rate  is  estimated  as  1  month  in  the  model. 

A  similar  structure  is  shown  for  the  rate  at  which  tasks  in  rework  (TBCoord)  are  completed.  Additionally,  a 
staicture  for  the  initial  assignment  of  tasks  is  provided  based  on  the  perceived  completion  rate  for  available  tasks 
(personnel  assigned  times  net  productivity  rate  of  those  personnel)  and  the  desired  period  of  design  completion 
(Design  Phase  Duration). 

The  effective  personnel  available  for  assignment  is  modified  by  three  inputs.  First,  the  basic  maiming  level 
represents  the  total  number  of  NAVSEA  and  contractor  personnel  assigned  to  a  particular  design  phase  and  design 
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discipline.  However,  not  all  men  are  created  equal.  Rather,  a  second  modification  is  necessary  to  reflect  the 
differences  in  project  experience  among  the  personnel.  It  is  assumed  that  although  all  engineers  and  designers  are 
equally  skilled,  those  who  are  with  the  project  for  more  than  six  months  are  more  productive  (by  an  assumed  factor 
of  20%)  due  to  experience  with  the  design  material  and  the  design  organization.  Finally,  as  schedule  pressure 
increase,  design  managers  may  begin  to  authorize  overtime  work  for  personnel.  As  a  first  order  dynamic,  overtime 
has  the  effect  of  fractionally  increasing  the  personnel  level  (by  as  much  as  150%  for  limited  durations)  without  the 
need  to  actually  hire  new.  inexperienced  designers.  However,  the  short  term  impacts  of  overtime  may  be  negated  by 
second  order  fatigue  impacts. 

5.4       Manpower  Availability  and  Assignment  Sectors 

5.4.1      Naval  Ship  Design  Organization  and  Resource  Structure 

The  Design  team  is  characterized  by  government  and  industry  participants.  The  level  of  participation 
transitions  from  mostly  governmental  to  mostly  commercial  over  the  course  of  the  program.  Figure  43  shows  the 
increasing  fraction  of  contractor  to  NAVSE  A  effort  that  took  place  over  the  course  of  the  DDG-5 1  design  program. 
In  tins  case,  the  NAVSEA  levels  were  relatively  consistent  throughout  the  program,  but  the  participation  of 
contractors  (both  private  and  other  government  agencies)  increases  exponentially  during  the  program.    The  impacts 
of  this  transition  (shown  in  Figure  5)  are  discussed.  Such  transitions  are  natural  when  considering  the  goal  of  each 
stage  of  the  process.  The  organization  that  results  from  the  transitions  and  manning  levels  must  reflect  by  the  need 
to  manage  the  design  and  to  assign  appropriate  resources  to  design  tasks.  As  presented  in  Chapter  4.  the  design 
tasks  are  naturally  broken  mto  design  disciplines  (23  are  listed)  These  disciplines  contain  the  structure  for 
manpower  organization  and  design  interfaces.  A  comparison  of  design  disciplines  and  manning  levels  is  shown  m 
Figure  44. 

Consider  the  organizational  charts  for  the  DDG-5 1  program  (Figure  45,  Figure  46,  Figure  47,  Figure  48). 
Each  element  of  the  organization  represents  a  portion  of  the  design  process  structure  captured  in  the  design 
disciplines.  For  instance.  Figure  45  represents  the  programmatic  organization  and  its  linkages  to  operational 
requirements  generation  (CNO),  engineering  resources  (NAVELEX.  NAVSEA  and  SYSCOMs).  and  the  design 
itself  (Ship  Design  Manager  and  Combat  Systems  Engineer).  The  Ship  Design  Manager  (SDM)  and  his/her 
organization  is  shown  in  Figure  46.  This  organization  reflects  the  different  task  groups  (machinery  engineering,  hull 
engineering,  integration  and  specifications,  etc)  under  which  the  specific  task  disciplines  are  completed.  Figure  47 
shows  the  combat  integration  and  design  organization  and  its  linkage  to  the  design  through  the  program  manager 
and  SDM.  Finally.  Figure  48  demonstrates  the  organization  for  cost  assessment  and  control.  Note  the  close  ties 
between  cost  and  weight  necessitated  by  the  costing  models  of  that  time.  For  early  design  stages,  the  participation 
of  shipbuilders  is  limited  as  shown  in  Figure  49. 
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Figure  43  DDG-51  Total  Design  Effort1 
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Data  is  complied  from  documentation  listed  in  Chapter  8.4. 
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Figure  44  DDG-51  Manpower  Transitions  and  Design  Task  Growth 

As  the  design  transitions  to  industry,  the  organization  must  likewise  transition.  The  government  design  team 
in  later  stages  includes  a  reduced  level  of  those  organizations  discussed  above  and  resident  Supervisor  of 
Shipbuilding  (SUPSHIP)  organization  that  provide  contract  oversight.    The  industry  participants  (coordinated 
through  the  shipbuilder)  include:14  Shipyard  Management  Teams  (Design  Management).  Functional  Design  Teams 
(Systems  Engineenng  and  Component  Integration).  Zonal  Design  Teams  (Transitional  Design  CAD  extraction  and 
Zonal  Design  and  Manufacturing  Design  Extraction),  and  the  Materials  Management  Team.  Within  detailed  design, 
shipbuilders  level  load  teams  to  maximize  resources  (teams,  designers  and  engineers,  computers)  while  providing 
production  facilities  with  design  products  in  a  timely  fashion.  Detailed  design  products  must  be  completed  Just  in 
Time  (JIT)  to  accommodate  design  changes  with  minimal  impact  to  completed  design  products.  In  other  words, 
design  products  are  not  completed  unless  manufacturing  is  ready  to  proceed.148  Typical  design  effort  for  the  DDG- 
5 1  included  in  the  model  consists  of  a  team  of  372  engineers  and  designers  working  in  two  shifts  (244  in  first  shift. 
1 13  in  the  second.)  The  designers  are  orgamzed  into  8  zonal  teams:  3  hull  specialty  teams.  3  machinery  specialty 
teams,  and  2  electronic  (combat  systems)  specialty'  teams.  The  teams  work  eight  zones  concurrently  in  design  and 
no  more  than  four  zones  transitioning  to  the  next  subphase  at  any  given  time.  Teams  to  provide  logistics 


146  Ibid 
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C.  R.  Lloyd,  "Design  Process  for  the  AEGIS  Destroyer  Program",  Presentation.  Bath  Iron  Works  D87  Class 
Design  Office.  November  18.  1997. 

148  David  Hinds,  interview  at  Bath  Iron  Works.  Brunswick.  ME,  November  15,  1997. 
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management  (ordering  and  parts  management)  and  design  management  (ECP  management,  information 
management,  etc)  are  included. 
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Figure  45  DDG-51  Ship  Design  Command  and  Program  Organization 
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Andy  Summers.  Contract  Design  History  for  the  Guided  Missile  Destroyer  (DDG  51  Class).  Naval  Sea  Systems 
Command.  Washington  DC.  June  1987.  page  2-27. 
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Figure  46  DDG-51  Ship  Design  Team  Organization 
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Ibid.,  page  2-29. 
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5.4.2      Manpower  and  Adjustments 

The  general  dynamic  behavior  of  resources  is  characterized  by  step  increases  in  manpower  from  Concept 
through  Detailed  Design,  ascending  and  declining  effort  within  each  phase,  and  small  numbers  of  governmental 
personnel  outsourcing  large  fractions  (50  to  75%)  of  design  effort  to  contractors.  This  is  captured  in  the  naval  ship 
design  process  model  by  splitting  manpower  into  two  flows:  NAVSEA  and  Contractors.  Figure  50  shows  this 
structure.  NAVSEA  personnel  are  those  personnel  that  are  considered  free  to  the  program  from  a  budget  stand- 
point. However,  there  are  fewer  NAVSEA  personnel  available  and  the  first  order  assignment  of  personnel  is  more 
difficult  as  fewer  become  available    Contractor  personnel  flows  include  all  those  personnel  that  reqiure  budget 
expenditures  to  work.  They  include  other  government  agencies  (OGAs)  such  as  the  Navy  labs,  ship  design 
contractors  such  as  JJMA  or  AME,  and  shipyards  such  as  BIW.  As  discussed  previously  (see  Chapter  5.3).  the 
flows  explicitly  include  the  maturing  of  designers  over  the  course  of  the  project. 
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Figure  50  Naval  Ship  Design  Process  Model  Manpower  Sector 

Given  the  available  personnel,  it  is  necessary  to  determine  the  desired  number  of  personnel  to  be  added  or 
removed  from  those  flows  (Figure  51)  and  the  distribution  of  personnel  requirements  between  government  and 
private  resources  (Figure  52).  Several  noteworthy  properties  are  demonstrated  in  these  structures.  First,  overtime  is 
modeled  to  reflect  the  means  by  which  managers  assess  overtime  needs  (Indicated  Overtime  Required  and  the  Effect 
of  Schedule  Gap  on  Overtime)  and  the  impact  of  overtime  for  extended  periods  on  productivity  (Fatigue).  Fatigue  is 
a  stock  because  the  accumulation  of  fatigue  does  build  over  time  and  takes  time  to  decrease  again.  Secondly, 
manpower  loading  levels  (seen  Figure  43)  show  decreases  in  both  total  effort  and  percentage  of  contractors  when 
approval  stages  begin.  Table  functions  for  the  effect  of  approval  phase  on  desired  manpower  and  on  NAVSEA 
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fractions  are  also  included.  The  model  determines  a  desired  manpower  level,  adjusted  by  these  effects,  and  uses  tins 
value  to  requisition  new  personnel  or  release  personnel  based  on  a  perceived  manpower  gap  (manpower  shortage). 
The  shortage  is  distributed  by  the  desired  fraction  of  NAVSE A  personnel  to  be  hired.  If  personnel  are  to  be 
released,  the  model  attempts  to  release  new  personnel  prior  to  experienced  manpower.  This  effect  is  included  based 
on  interviews  with  managers  from  NAVSEA  and  BIW 
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Figure  51  Naval  Ship  Design  Process  Model  Desired  Manpower  Sector 
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Figure  52  Naval  Ship  Design  Process  Model  Manpower  Allocation  Sector 
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5.5       Financial  Sector 

The  financial  sector  is  the  link  between  the  design  process  model  (schedule)  and  the  available  design  budget. 
This  process  fits  within  the  context  of  the  formal  DoD  budgeting  process:  the  Planning.  Programming  and 
Budgeting  System  (PPBS).  The  PPBS  is  a  multi-year  budgeting  system  that  addresses  all  areas  of  military  budget 
including  both  operational  expenditures  and  acquisition.  Program  managers  must  interact  with  the  PPBS  to  secure 
funding  for  future  design  and  acquisition  costs  and  continue  to  justify  current  expenditures. 

The  system  consists  of  three  distinct  phases.  During  the  Planning  Phase,  mid  term  and  long  range  defense 
goals  are  assessed  against  perceived  threats.  This  is  similar  to  the  dynamics  seen  in  Chapter  2.1.  Based  on  results  of 
this  analysis,  the  National  Security  Council  issues  the  National  Military  Strategy  Document  (NMSD).  The 
document  is  issued  in  July  of  odd  numbered  years.  Between  then  and  November  30th  of  the  same  year,  the 
document  is  reviewed  and  re-issued  as  the  Defense  Planning  Guidance  (DPG).  The  document  defines  the  fiscally 
constrained  force  structure  into  which  the  program  manager  must  attempt  to  secure  a  portion  of  funds. 

The  second  phase  is  the  Programming  Phase.  This  phase  establishes  the  allocation  of  funds  to  the  specific 
force  elements  that  must  be  supported.  There  are  eleven  force  elements  which  include  strategic  forces,  general 
purpose  forces,  research  and  development,  etc.  The  goal  of  this  phase  is  to  establish  the  optimized  mix  of 
manpower  and  equipment  required  to  satisfy-  the  national  defense  posture.  By  April  of  the  next  year  (even  year) 
Program  Objective  Memorandums  (POMs)  are  prepared.  The  POMs  reflect  "a  detailed  expression  of  proposed 
programs  by  program  element,  schedules  and  funding  6  years  into  the  future,  with  force  levels  3  years  beyond 
that. .  Each  POM  submission  is  a  modification  of  the  approved  FYDP  (Future  Years  Defense  Program),  updated  to 
reflect  current  guidance  from  OSD  (Office  of  the  Secretary  of  Defense),  with  2  fiscal  years  being  added  during  each 
(POM)  cycle."154  By  September,  all  POM  issues  are  debated  and  approved  with  the  Secretary  of  Defense  approving 
these  submissions  as  the  basis  for  the  Budget  Estimate  Submission  (BES).  The  program  manager,  based  on  the 
current  and  future  needs  of  his  or  her  program,  seeks  to  influence  the  POM  submission  to  gain  additional  funding  for 
the  program  as  necessary.  However,  the  nature  of  this  system  means  that  actual  funding  requests  are  not  realized  for 
at  least  2  years  from  submission  and  possibly  4  years  if  the  submission  falls  at  the  end  of  the  POM  cycle. 

The  final  phase  is  Budgeting.  From  September  through  December,  the  BES  and  POM  are  assessed  for 
categorical  allocations  to  five  primary  budget  categories:  RDT&E,  Procurement,  Operation  and  Maintenance. 
Military  Personnel  and  Military  Construction.  During  tins  period  final  budget  adjustments  known  as  Program 
Budget  Decisions  (PBDs)  are  performed  to  account  for  cost  factors,  risks  in  projections,  the  timing  of  related  events, 
jointness  of  requests,  and  uniformity.  The  final  budget  is  submitted  to  the  President  the  first  Monday  after  the  3rd  of 
January  in  the  next  year  (odd).  The  budget  is  debated  and  approved  for  activation  the  following  fiscal  year  (October 
of  the  year  of  submission). 


154  Defense  Svstems  Management  College.  The  Program  Manager's  Notebook.  Fort  Belvoir.  VA.  June  1993. 
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The  obvious  delays  in  the  timescale  of  the  PPBS  must  be  accounted  for  in  the  development  of  the  naval  ship 
design  model.  Coupled  with  the  target  profile  for  engineering  expenditures  during  the  design  process,  the  PPBS 
manifests  itself  as  a  funding  delay  when  increased  budget  needs  arise  to  meet  design  schedule  deadlines.  Consider 
the  typical  engineering  cost  profile  for  a  surface  combatant  program  shown  in  Figure  53.  Based  on  past  cost  profiles 
(such  as  is  shown  below),  the  desired  schedule  and  the  complexity  of  the  design  program  (total  tasks  to  complete), 
the  program  manager  must  submit  a  budget  request  through  the  PPBS.  Funding  is  not  granted  in  excess  of 
perceived  needs,  so  the  program  manager  are  constrained  to  a  fixed  schedule  and  budget.  However,  as  process 
dynamics  cause  the  schedule  to  slide  and  the  engineering  cost  fluctuate  as  does  manpower  loading  (Figure  43), 
funding  shortfalls  can  occur.  The  time  required  to  overcome  the  shortfalls  is  equivalent  to  the  duration  of  the  PPBS. 


$250,000,000 


-.  $200,000,000 

8 

>- 

~  $150,000,000 
m 


|  $100,000,000 

<u 
a 

x 

m     $50,000,000 
$0 


May-79 


Engineering  Cost  Profiles 


-Cumulative  Expenditures 
-Annual  Expenditures 


Oct-SO 


Feb-82  Jul-83 

Design  Phase  Start  Date 


Nov-84 


Mar-86 


Figure  53  DDG-51  Engineering  Expenditures155 

Figure  54  shows  the  dynamic  budgeting  and  allocation  flow  for  the  naval  ship  design  process.  The  delays 
from  the  PPBS  are  modeled  as  a  first  order  delay  through  Change  to  Budget  and  Time  to  Change  Budget.  The  Time 
to  Change  Budget  is  set  to  2  years  to  reflect  the  average  PPBS  cycle  time.  The  Funding  Period  and  Fiscal  Counter 
model  the  fiscal  allocation  of  funds  to  the  program.  Actual  spending  becomes  a  function  of  total  effective 
manpower  costs  (i.e.  total  contractors  plus  overtime).  Note  that  the  model  explicitly  capture  overhead  costs.  These 
costs  are  included  in  the  value  of  the  contracting  fee  ($6597  per  engineer  per  month).156 

Funding  shortfalls  occur  as  two  dynamics.  First,  a  funding  gap  is  created  that  is  relieved  by  first  order  control 
through  Change  to  Budget  and  subsequent  flow  through  the  fiscally  controlled  Program  Budget  Rate.  The  second 
effect  is  the  temporary  decrease  in  funding  to  contractors  (i.e.  release  of  contractors)  and  the  increase  of  NAVSEA 
engineering  efforts  to  compensate.  As  budget  levels  rise  once  more,  these  trends  reverse.  Should  a  funding  surplus 
occur,  the  dynamic  is  reversed:  the  budget  decreases  over  time  and  the  program  assigns  increasing  levels  of 
contractors  to  consume  the  surplus. 


135  Naval  Sea  Systems  Command,  Ship  Design  Project  Histories:  Volume  11  1980-1989.  estimated  edit  date  June 
1984,  page  2.8. 


156 


Ibid.  FY  1996  dollars  projected  from  1985  engineering  cost  estimates  for  contractors. 
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The  final  element  of  the  model  is  the  explicit  modeling  of  contract  types.  Within  the  contracting 
environment,  program  managers  have  the  option  of  awarding  new  Requests  for  Proposals  (RFPs)  or  using  existing 
contracts  through  other  program  offices.  There  are  advantages  and  disadvantages  to  each.  New  awards  provide  the 
manager  (PM)  with  a  dedicated  contract,  tailored  to  the  current  program  with  no  overhead  costs  imposed  by  external 
authorities.  However,  the  RFP  process  can  take  as  long  as  18  months  to  establish  and  begin  actual  design  work.  For 
this  reason  the  PM  may  offer  to  fund  an  existing  contract  being  managed  by  a  NAVSEA  directorate  or  other 
program  office.  Such  an  approach  offers  rapid  access  to  contractors  and  design  resources.  However,  the  managing 
office  imposes  an  overhead  charge  of  10%  or  more  of  the  design  costs.  Additionally,  the  contract  may  not  be 
tailored  to  the  particular  design  problem  being  studied.  As  such,  the  PM  must  decide  on  an  appropriate  policy  for 
allocation  of  contract  tvpes.  In  the  model,  these  allocations  are  fixed  as  percentages  of  contractor  assignment.  The 
percentages  transition  to  RFPs  as  the  process  matures. 
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Figure  54  Naval  Ship  Design  Process  Model  Financial  Sector 
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Hypothesis  Testing,  Modeling  Results  and  Conclusions 


6.1       Baseline  Model  Results 

The  desired  behavior  for  the  baseline  model  is  to  match  the  levels  and  dynamics  of  the  DDG-5 1  program. 
Obtaining  specific  data  for  such  an  effort  is  difficult.  As  was  noted  in  the  DAC  study,  program  management 
statistics  are  highly  variable  in  quality  and  availability,  particularly  with  respect  to  manpower  efforts.  Specific 
documents  with  such  information  have  been  published.  These  include  several  NAVSEA  documents:  the  DDG-5 1 
Guided  Missile  Destroyer  Preliminary  Design  History,  the  Contract  Design  History  for  the  Guided  Missile 
Destroyer  (DDG  5 1  Class),  and  the  Ship  Design  Project  Histories:  Volume  I.  II  and  HI.  From  these  documents, 
manpower  and  budgetary  trends  can  be  extrapolated  Figure  55  illustrates  the  NAVSEA  effort  for  several  recent 
design  programs.  Strategically.  NAVSEA  has  reduced  (over  time  from  FFG-7  to  CG-47  to  DDG-5 1)  the  numbers 
of  government  personnel  assigned  to  the  program.  Operationally,  the  graph  demonstrates  increasing  engineering 
efforts  through  each  design  phase  with  several  dynamic  rises  midway  through  each  program,  declines  at  the  end  of  a 
phase,  and  an  extended  level  of  decrease  at  the  end  of  contract  design. 
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Figure  55  Early  Phase  NAVSEA  Personnel  Effort  for  Surface  Combatant  Design  Programs 

Figure  43  shows  the  significant  difference  in  numbers  of  government  and  contractor  personnel.  The 
NAVSEA  effort  is  small  compared  to  that  of  Other  Government  Agencies  (OGA)  and  contractors.  Generally,  the 
trend  for  each  category  of  personnel  follows  the  total  trend  effort  for  the  program.  There  are  some  unusual 
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variations  in  contractor  and  OGA  effort.  However,  as  each  of  these  types  require  budget  expenditures  to  acquire. 
The  variations  represent  a  choice  by  the  program  manager  to  select  one  type  of  contractor  over  the  other. 

Another  noteworthy  d>Tiamic  is  the  transition  between  design  disciplines  over  the  course  of  the  project. 
Recall  the  design  disciplines  and  design  products  discussed  in  Chapter  4.  Consider  the  trends  shown  in  Figure  56. 
In  early  stages  of  design,  programmatic  interfaces  dominate  along  with  a  significant  effort  in  system  performance 
assessment.  Other  engineering  efforts  provide  input  to  these  categories,  but  the  delivered  products  are  substantially 
less.  This  reflects  the  early  goal  of  design  to  determine  requirements  and  needs.  As  the  program  matures, 
increasing  effort  is  in  high  risk  design  categories  such  as  combat  systems  and  marine  systems  integration.  In  the 
final  stages  of  the  design  process,  very  specific  efforts  in  component  level  definition  (hull  structural  drawings, 
arrangements  drawings,  machinery  arrangements,  MELs  and  parts  lists)  dominate  the  engineering  effort. 
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Figure  56  Design  Product  Trends  (Number  of  Total  Deliverables)158 

Based  on  these  trends  and  the  dynamics  discussed  in  Chapters  4  and  5.  the  naval  ship  design  process  model 
was  adjusted  to  match  the  baselme  behavior  of  the  DDG-5 1  program.  Figure  57  shows  the  model  results  for  total 
assigned  manpower  compared  to  the  DDG-5 1  program.  The  model  results  were  calibrated  once  by  adjusting  the 
nominal  productivity  rates  (Adjust  Rate,  see  Figure  42)  to  match  project  duration  to  the  DDG-5 1.  These  results 
demonstrate  the  effectiveness  of  the  dynamic  model  to  capture  the  dynamic  behavior  of  a  complex  process. 


157 
158 


Data  is  complied  from  documentation  listed  in  Chapter  8.4. 
Ibid. 
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Although  not  all  levels  are  captured  precisely,  the  dynamic  events  are.  Note  the  agreement  of  the  model  and  data 
from  months  35  to  45  and  from  months  50  to  90. 
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Figure  57  Initial  Baseline  Results  from  the  Naval  Ship  Design  Process  Model 

The  differences  between  the  model  and  data  may  be  accounted  for  in  several  ways.  First,  note  that  the  data 
shows  initial  manpower  levels  of  over  50  personnel.  This  is  deceiving.  The  program  had  actually  started  concept 
studies  as  early  as  1978.  The  model  starts  from  0  personnel  in  1980  (milestone  0  for  the  program).  Another  issue 
with  the  data  is  that  it  implies  all  personnel  assigned  to  the  project  are  working  on  the  project  100%  of  the  month.  In 
reality.  NAVSEA  personnel  and  contractors  on  existing  contracts  may  have  worked  only  a  fraction  of  the  time  on 
the  DDG-5 1  and  the  remaining  time  on  other  projects.  As  such,  the  data  overestimates  manning  levels. .  .particularly 
in  early  design  phases.  Finally,  the  model  was  only  calibrated  using  a  single  variable.  Given  more  time  and 
resources,  the  model  could  be  calibrated  more  accurately  using  sensitivity  analysis  of  all  model  constants  and 
through  further  refinements  of  the  model  behaviors. 

These  minor  issues  do  not  detract  from  the  value  of  the  results.  The  model  does  capture  the  process 
dynamics.  This  alone  is  worthwhile  as  it  provides  insight  into  the  causes  of  specific  process  behaviors.  For 
instance,  the  oscillations  at  month  45  and  month  57  correlate  to  the  end  of  fiscal  cycles  where  funding  shortfalls 
occurred.  Armed  with  this  prediction,  a  program  manager  may  be  able  to  negotiate  a  budget  increase  to  prevent 
future  oscillations  and  subsequent  schedule  shifts.  Thus,  the  model  provides  useful  results  and  can  be  used 
effectively  to  assess  specific  hypotheses. 
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6.2       What  if  CAE/CAD/CAM  Are  Used? 

The  first  hypothesis  examined  with  the  model  is  how  the  application  of  computer  based  design  tools  effects 
the  process  dynamics,  manpower  loading  and  duration.  In  earlier  chapters,  some  specific  dynamic  impacts  of 
computer  aided  engineering  design  and  manufacturing  (CAE/CAD/CAM)  were  addressed.  Computer  based  design 
reduces  error  rates  by  allowing  automated  interference  checking  and  QA  of  design  products.  Several  shipbuilders 
(BIW.  Newport  News  Shipbuilding)  have  reported  these  improvements.  However,  reduced  errors  rates  have  not 
come  without  serious  growing  pains.  At  BIW,  the  use  of  early  versions  of  CAD  resulted  in  very  high  false  error 
rates,  a  false  error  being  the  designation  of  an  interference  or  blockage  in  the  CAD  model  when  no  such  problem 
exists.  From  1991  through  1997,  the  engineering  division  used  3  revisions  of  the  CAD  software,  with  false  error 
rates  per  zone  per  design  review  decreasing  from  an  average  of  1000  in  1991  to  100  in  1994  to  10  or  less  in  1997. 
Although  these  rates  reflect  exponential  improvements,  the  five  years  of  learning  and  adjustment  were  difficult  to 
justify.159 

Other  organizations  have  claimed  substantial  reductions  in  design  time  with  CAD  system  usage.  The 
Daewoo  Shipyard  of  Korea  installed  a  CAD  system  to  perform  structural  design.  Table  42  shows  the  trends  m 
usage  of  that  system  at  Daewoo.  From  the  data,  it  is  quite  apparent  that  the  organization  was  committed  to  CAD 
modernization.  The  number  of  computers  was  increased  while  the  number  of  designers  and  the  design  duration 
were  reduced.  Could  these  results  be  realized  for  the  naval  ship  design  process? 


Item 

•89 

•90 

•92 

'94 

No.  of  Workstations 

10 

40 

60 

82 

No.  of  Designers  (No.  using  Workstations) 

190 
(20) 

156 
(90) 

156 
(110) 

164 
(118) 

Computerized  Drawmgs  (%) 

26 

50 

92 

96 

Detailed  Design  Period  (months) 

7.5 

7.0 

6.0 

5.5 

Table  42  Performance  Status  of  Steerbear-Hull  Design  System  at  Daewoo  Shipbuilding160 

Suppose  a  specific  CAE/CAD/CAM  system  is  proposed.  Such  a  system  provides  an  integrated  design  and 
data  management  environment  for  the  design  process    Based  on  the  Daewoo  experience,  system  designers  advertise 
the  following  attributes  for  the  system: : 

•  Error  rate  is  reduced  by  50%  (computer  integration  and  design  automation  should  reduce  errors) 

•  Error  discovery  is  increased  by  50%  (CAD  software  provides  explicit  interference  detection) 

•  Experience  (learning)  time  is  increased  to  6  months16'  (computer  systems  do  require  time  for  training  and 
familiarization) 

•  Coordination  rate  is  50%  faster  (data  transfer  ranges  from  instantaneous  with  a  product  model  to 
improved  with  email). 


David  Hinds,  interview  at  Bath  Iron  Works.  Brunswick,  ME,  November  15.  1997 


159 

Chris  Kennison,  KCS  Users  Meeting  Minutes.  Kockums  Computer  Systems,  Annapolis.  MD,  October  31,  1997. 
David  Hinds,  interview  at  Bath  Iron  Works.  Brunswick.  ME,  November  15,  1997. 
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Based  on  these  properties,  a  model  run  is  developed.  The  results  are  shown  compared  to  the  baseline  run  in  Figure 
58.  The  result  of  these  changes  is  a  13  month  reduction  in  the  total  design  process.  This  is  consistent  with  the 
results  seen  for  Daewoo  Shipbuilding.  Some  dynamics  are  particularly  noteworthy.  The  concept  design  process 
does  not  appear  to  change.  The  preliminary  design  process  begins  slightly  earlier,  but  really  takes  off  over  the 
baseline  case  by  month  30.  Specifically,  the  design  interactions  are  improved  by  faster  coordination  and  reduced 
errors.  Thus,  more  tasks  are  available  for  final  iteration  in  preliminary  design  at  an  earlier  point.  The  contract 
design  starts  5  months  earlier  and  detailed  design  is  able  to  start  8  months  earlier.  Thus,  the  application  of  computer 
design,  applied  to  a  few  specific  variables  (error  rates,  learning  and  coordination)  provides  over  a  one-year  cycle 
time  reduction.  Note,  however,  that  the  process  did  not  reduce  the  number  of  personnel  and  even  increased 
manpower  levels  in  early  stages. 
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Figure  58  Comparison  of  Baseline  Model  to  CAE/CAD/CAM  Hypothesis 

What  if  the  advertised  improvements  are  not  fully  realized9  Such  a  circumstance  is  consistent  with  the 
implementation  difficulties  described  previously  for  BIVV.  Specifically,  suppose  the  error  rate  from  baseline 
methods  is  only  reduced  by  25%  vice  50%.  The  model  results  for  this  case  are  shown  in  Figure  59.  The  results 
demonstrate  that  the  process  duration  is  not  sensitive  to  a  change  in  error  rate.  However,  the  number  of  personnel 
required  to  maintain  that  schedule,  particularly  in  contract  and  detailed  design,  is  very  sensitive  with  a  12%  increase 
in  personnel  assigned  over  the  project.  As  a  result,  manpower  costs  increase  by  over  $30  million  due  to  the 
unrealized  potential  of  the  CAD  system. 
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This  example  indicates  the  power  of  system  dynamics  modeling  to  analyze  schedule  risks 
associated  with  process  improvements. 
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Figure  59  Sensitivity  of  CAE/CAD/CAM  Hypothesis  to  Error  Rate  Improvements 

6.3       What  if  Concurrent  Engineering  and  IPTs  Are  Applied 

Concurrent  Engineering  and  IPTs  are  proposed  as  methods  to  improve  responsiveness  of  the  design  process. 
Previous  discussions  examined  some  specific  dynamic  impacts  of  concurrent  engineering.  IPTs.  and  IPPD.  The 
ability  of  engineers  to  effectively  communicate  with  one  another  should  reduce  the  number  of  design  iterations 
required  for  convergence.  Additionally,  concurrent  engineering  front  loads  many  design  tasks  earlier  in  the  process 
such  as  producibility. 

For  this  case,  suppose  process  improvements  are  advertised  to  provide  the  following  process  modifications: 

•  Error  discover)  increased  by  25%  (teaming  will  provide  continuous  data  exposure  to  multiple  designers 
and  disciplines) 

•  Coordination  rate  is  100%  slower  (due  to  communication  overhead  costs) 

•  Design  feedback  is  reduced  by  50%  (teaming  provides  better  knowledge  among  designers  of  task 
interaction  impacts  and  communication  of  data  trends) 
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Approval  and  Review  periods  are  reduced  by  50%  (teaming  can  provide  interim  communication  of 
design  requirements,  attributes  and  effectiveness  throughout  the  process  rather  than  during  specific 
approval  and  review  periods). 
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Figure  60  Comparison  of  Baseline  Model  to  Concurrent  Engineering/IPT  Hypothesis 

Applying  these  process  modifications  to  the  model  provides  results  as  shown  in  Figure  60.  These  results 
show  a  16  month  reduction  in  the  total  design  process    Additionally,  the  net  personnel  assigned  for  the  entire  project 
(integration  of  the  graphs)  is  decreased  by  10%.  This  is  an  expected  benefit  from  the  use  of  cross-disciplinary 
design  teams.  Some  of  the  dynamics  are  particularly  interesting.  All  the  design  phases  occur  faster  and  with  fewer 
personnel.  The  faster  design  periods  allow  the  process  to  better  weather  budget  transitions  by  compacting  the  design 
phases  (preliminary  and  contract  design)  into  periods  of  about  12  months  each.  The  preliminary  design  process 
begins  slightly  earlier,  but  really  takes  off  over  the  baseline  case  by  month  30.  Finally,  the  lead  ship  design  occurs 
so  much  more  quickly  that  the  manufacturing  design  is  actually  delayed  (represented  by  the  saddle  in  the  curve)  to 
await  the  JIT  pull  from  production.  Generally,  we  can  conclude  that  the  application  of  teaming  in  design  process,  as 
applied  to  a  few  specific  variables  (error  rates,  design  feedback,  approval  schedules,  and  coordination)  provides 
almost  a  one-and-a-half-year  cycle  time  reduction  and  overall  manpower  reductions. 

As  with  the  CAE/CAD/CAM  example,  sensitivity  analysis  provides  insight  for  risks  to  program  performance 
In  this  example,  suppose  design  feedback  is  only  reduced  by  40%  vice  50%.  Such  a  circumstance  would  occur  if 
design  requirements  were  continually  changing  such  as  during  the  end  of  the  Cold  War   The  result  is  a  lengthening 
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of  the  design  process  by  3  months,  a  4%  increase  in  manpower  costs  and  an  increased  requirement  for  personnel 
during  concept  design.  Again,  sensitivity  provides  the  program  manager  with  a  tool  to  assess  the  expected  impacts 
and  risks  of  proposed  process  improvements. 
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7       Conclusions  and  Future  Work 

7.1       Conclusions 

Most  schedule  analysis  tools  (PERT,  CPM.  DSM)  only  provide  the  ability  to  capture  hard  process  variables 
such  as  design  concurrence  or  phase  durations.  These  operationally  and  statistically  based  methods  fail  to  capture 
the  dominant  dynamic  influences  (human  factors,  error  propagation  and  design  feedback)  that  ultimately  lead  to 
schedule  growth.    Additionally  these  methods  do  not  accurately  reflect  non-linear  impacts  such  as  overtime,  fatigue, 
schedule  pressures  and  learning  curves  (see  Chapter  1.1.1).  For  these  reasons,  the  naval  ship  design  process  model 
is  necessary  and  useful.  System  dynamics  modeling  provides  one  of  the  few  means  to  assess  process  improvements 
that  must  incorporate  not  only  architectural  changes  to  the  process,  but  the  responses  of  real  people  to  those  changes. 
The  obvious  physical  relationships  of  naval  architecture,  marine  engineering,  combat  systems  engineering  and 
systems  engineering  are  explicitly  modeled.  Cost  constraints  and  policy  reactions  are  captured.  These  impacts  are 
captured  in  many  other  system  dynamics  models  as  well  (see  Tan  and  Bligh.  1998  and  Rodngues  and  Bowers. 
1995.)  However,  these  models  do  not  capture  the  issues  of  multi-functional  design,  design  feedback  or  program 
policies  unique  to  naval  ship  design.  For  this  reason,  the  inclusion  of  the  DSM  structure  in  the  naval  ship  design 
process  model  is  necessary. 

The  naval  ship  design  process  model  (see  Chapter  8.7  for  the  baseline  model)  contains  the  necessary  detail  to 
capture  the  dynamics  of  a  ship  design  program.  Specifically,  the  DDG-5 1  program  behavior  is  captured  (see 
Chapter  6. 1 )    As  the  DDG-5 1  program  is  now  almost  two  decades  old.  not  all  baseline  variables  are  appropriate  for 
use  with  current  design  programs 

For  instance,  there  is  a  trend  to  shift  greater  levels  of  system  analysis  into  concept  design  and  to  more  fully 
develop  the  concept  variants  presented  for  AoA  consideration.  By  this  trend,  concept  design  in  the  1990's 
increasingly  examines  details  reserved  for  preliminary  design  in  the  1980s.  To  accommodate  this  trend  model 
variables  for  initial  tasks  lev  els  must  increase  in  the  concept  design  phase  to  reflect  the  increased  design  analysis. 
Additionally,  the  introduction  of  integrated  design  environments  increases  productivity  relative  to  specific  design 
tasks   This  is  reflected  in  the  trends  shown  previously  in  Table  42.  However,  as  the  level  of  analysis  increases  more 
rapidly  than  productivity,  the  resultant  design  rate  may  actually  decrease.  Such  specific  modifications  to  variables 
are  necessary  to  assess  modern  programs  with  the  naval  ship  design  model. 

Despite  the  need  for  changing  variables,  the  generic  structure  of  the  naval  ship  design  model  (see  Chapter  5) 
is  accurate  and  does  reflect  the  policy  and  process  mechanisms  contained  in  the  ship  design  process.  Thus,  with 
modifications  of  variables  consistent  with  current  design  process  trends  (see  discussions  in  Chapters  4  4  through  4.9) 
and  calibration  of  those  variables,  the  model  is  applicable  to  ship  design  programs  like  the  DD-2 1  or  CVX. 

Further,  the  baseline  model  provides  a  structure  to  judge  the  impacts  of  potential  process  improvements  and 
the  risks  associated  with  the  assumptions  of  those  improvements.  As  demonstrated  in  Chapters  6.2  and  6  3,  gains  in 
cycle  time  and  manpower  reduction  are  sensitive  to  the  assumptions  of  the  proposed  improvements.  Program 
managers  can  test  assumptions  and  design  the  process  organization  to  optimize  schedule  performance.  Additionally, 
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the  program  manager  can  use  the  model  to  trade-off  cycle  time  against  mission  effectiveness  and  cost  as  determined 
by  their  respective  analysis  methods  (see  Chapters  1.1.2  and  1.1.3). 

7.2       Future  Uses  and  Work 

The  naval  ship  design  process  dynamic  model  has  three  potential  future  uses: 

1 .  Testing  of  specific  management  policies  and  process  improvements 

2.  Understanding  of  the  behavioral  forces  at  work  in  a  process 

3 .  Prediction  of  future  trends 

For  policy  testing,  the  model  provides  a  means  to  test  and  optimize  a  management  plan  (such  as  when  to 
allow  schedule  shift  or  what  fraction  of  NAVSEA  personnel  to  involve  in  a  project.)  However,  a  note  of  caution  is 
necessary.  The  full  use  of  any  model  for  policy  implementation  must  be  contingent  on  the  support  of  all  process 
participants.  Specifically,  if  knowledgeable  personnel  have  not  reviewed  the  model's  structure  and  behavior,  it 
implementation  will  be  flawed  (i.e.  the  dynamics  are  correct  but  the  model  structure  is  not  tangible  or  operationally 
accurate.)  The  result  would  be  accurate  baseline  beha\ior  but  inaccurate  hypotheses.  As  such,  continuous 
comparison  of  the  model  with  observed  results  must  take  place.  It  is  in  this  manner  that  the  model  can  provide 
understanding  of  behavior  forces. 

The  model  can  also  be  studied  to  reveal  behavior  forces  within  the  design  process.  Through  constant  dialog, 
process  participants  and  modelers  can  begin  to  recognize  the  causes  of  cycle  time  growth,  the  dynamics  of 
undiscovered  errors,  the  effects  of  personnel  changes  on  the  process,  and  a  multitude  of  other  process  behaviors.  As 
managers  change  their  mental  models  of  the  process  to  reflect  more  accurately  the  dynamic  impacts  of  their 
management  decisions,  process  improvements  can  be  better  implemented.  Additionally,  process  authorities  are 
better  armed  with  tools  to  address  critics  and  combat  constraining  externalities. 

Armed  with  accurate  models  and  understanding  of  those  models,  process  managers  can  begin  to  predict  and 
gauge  the  future  trends  of  process  improvements.  As  demonstrated  in  Chapter  6,  initial  results  for  improvements 
such  as  IPTs  and  SBD  have  the  potential  to  significantly  reduce  cycle  time.  The  next  step  is  the  calibration  of  the 
model  to  a  current  program  (such  as  DD-2 1)  and  monitoring  the  expected  results  against  observation.  In  this 
maimer,  a  program  manager  has  the  necessary  metrics  to  modify'  management  policies  before  critical  thresholds 
(spiraling  cost  or  schedule  growth)  are  reached 

Future  modeling  work  to  support  and  implement  the  above  listed  uses  include: 

1)  Discuss  the  model  with  program  participants.  Calibrate  and  validate  critical  dynamics  such  as  cost  impacts, 
scheduling  methods  and  manpower  allocation. 

2)  Integrate  the  model  with  other  dynamic  models  (McCue,  1997)  for  analysis  across  design  and  production.  The 
naval  ship  design  process  model  may  ultimately  be  incorporated  in  a  life  cycle  process  analysis. 

3)  Develop  dynamic  models  for  externalities  (arms  race  dynamic,  etc)  and  incorporate  these  dynamics 
endogenously  to  the  model. 

4)  Refine  the  model  to 

a)     improve  manpower  allocations  for  task  coordmation  and  QA. 
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b)    improve  Program  Planning  Budgeting  System  (PPBS)  components  relative  to  cost 

5)  Obtain  improved  baseline,  comparative  data  by 

a)  examining  additional  metrics  (other  than  manpower  levels)  at  concept  and  prehrninary  design  to  reduce  the 
inaccuracies  of  collected  data 

b)  examining  dynamic  fluctuations  of  detailed  design  manpower  levels  from  shipyards  and  SUPSHTP  offices 

6)  Perform  dedicated  case  studies  to  analyze  hypotheses  such  as 

a)  the  impact  of  shifting  design  transition  from  government  to  industry  earlier  in  the  process 

b)  the  dynamic  impacts  of  scope  growth  in  an  open  architecture  design 

These  model  improvements  will  provide  greater  fidelity  and  usefulness  of  the  model  for  future  use  in 
assessing  the  system  optimization  and  dynamics  of  the  naval  ship  design  process. 
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8.3       Glossary  and  Abbreviations 

3-D  Product  Model  -  Captures  all  of  the  information  needed  to  describe  a  ship 

AoA  -  Analysis  of  Alternatives,  an  analysis  of  the  costs  and  operational  effectiveness  of  alternative  material  systems 

to  meet  a  mission  need  and  the  associated  program  for  acquiring  each  alternative. 
ASR  -  Alternative  System  Review 
ASR  -  Acquisition  Strategy  Report,  describes  the  acquisition  approach  to  include  streamlining,  sources,  competition 

and  contract  types  throughout  the  period  from  beginning  of  Phase  I.  through  end  of  production.  An  annex  to 

the  IPS. 
Architecture  -  A  structure  that  shows  the  elements  and  their  relationship  for  a  set  of  requirements  or  a  system 

concept  or  both. 
ATC  -  Affordability  through  Commonality  Program 
BIW  -  Bath  Iron  Works 
CALS-GCO  (Continuous  Acquisition  and  Life  Cycle  Support-  Government  Concept  of  Operations):  A  document. 

Provides  the  Government  Concept  of  Operations  (GCO)  for  data  associated  with  the  SC  2 1  Program  in 

conformance  with  the  basic  strategy  of  Continuous  Acquisition  and  Life-Cycle  Support  (CALS). 
CDR  -  Critical  Design  Review,  review  conducted  to  determine  that  the  detailed  design  satisfies  performance  and 

engineering  requirements  of  the  development  specification;  to  establish  the  detailed  design  compatibility 

among  the  item  and  other  items  of  equipment,  facilities,  computer  programs,  and  personnel;  assesses 

producibility  and  risk  areas;  and  to  review  the  preliminary  product  specifications. 
CDRL  -  Contract  Data  Requirements  List.  Document  used  to  order  and  require  delivery  of  data.  Tells  contractor 

what  data  to  deliver,  when  and  how  it  will  be  accepted,  where  to  look  for  instructions,  etc. 
COEA  -  Cost  and  Operational  Effectiveness  Analysis.  OBSOLETE,  superceded  by  AoA. 
Concurrent  Engineering  -  A  systematic  approach  to  the  integrated,  concurrent  design  of  products  and  their  related 

processes,  including  manufacture  and  support.  This  approach  is  intended  to  cause  developers,  from  the 

beginning,  to  consider  all  elements  of  the  system  life  cycle  from  requirements  development  through  disposal. 

including  cost,  schedule  and  performance. 
Configuration  item  -  An  item  mat  satisfies  a  documented  set  of  requirements  and  is  designated  for  separate 

configuration  management  to  include  any  item  required  for  logistic  support  or  designated  for  separate 

procurement. 
Configuration  management  -  For  configuration  items,  (1)  the  identification  and  documentation  of  the  configuration. 

(2)  the  control  of  changes  to  the  items  or  their  documentation,  (3)  configuration  status  accounting,  and  (4)  the 

auditing  to  confirm  that  conformance  to  all  requirements  has  been  verified. 
Cost  As  an  Independent  Variable  -  Methodologies  to  acquire  and  operate  affordable  DOD  systems  by  setting 

aggressive,  achiev  able  cost  objectives  and  managing  achiev  ement  of  these  objectives.  Cost  objectives  shall 
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be  set  to  balance  mission  needs  with  projected  out-year  resources,  taking  into  account  anticipated  process 

improvements  in  both  DOD  and  defense  industries. 
COTS  -  Commercial  off  the  Shelf 
CPM  -  Critical  Path  Method 
CVX  -  Next  generation  aircraft  carrier 
DAB  -  Defense  Acquisition  Board,  the  senior  DOD  acquisition  review  board  chaired  by  the  Under  Secretary  of 

Defense  for  Acquisition.  The  Vice  Chairman  of  the  Joint  Chiefs  of  Staff  is  the  Vice-Chair   Other  members 

include  the  Deputy  USD( Acquisition).  Acquisition  Executives  of  the  armed  services;  the  Director  of  Defense 

Research  and  Engineering;  the  Assistant  Secretary  of  Defense  for  Program  Analysis  and  Evaluation;  and  the 

Comptroller  of  the  DOD. 
DARC  -  Defense  Acquisition  Regulatory  Council,  one  of  two  councils  authorized  to  generate  changes  to  the  Federal 

Acquisition  Regulation  (FAR).  DARC  members  are  from  the  Office  of  the  Under  Secretary  of  Defense  for 

Acquisition,  the  DOD  components  and  NASA. 
DCP  -  Decision  Coordinating  Paper.  OBSOLETE,  superceded  by  IPS. 
DD-2 1  -  Next  combatant  ship  program  after  DDG-5 1 ,  also  designated  SC-2 1 . 
DDG-5 1  Flight  IIA  -  Added  helicopter  support  and  lengthened  base  design 
Defense  Acquisition  Executive  Summary  (DAES)  -  summary  report  of  program  progress  presented  to  Office  of 

Secretary  of  Defense  (OSD)  for  review. 
Design  -  noun:  The  result  of  designing. 
Design  -  verb:  Architecting  and  selecting  products  (including  processes)  and  corresponding  personnel  manpower. 

skill  levels,  and  specialized  training  that  satisfy  all  requirements  and  describing  them  so  that  the  products  can 

be  manufactured  or  coded,  verified,  deployed,  operated  supported  and  disposed  of  and  so  that  the  personnel 

can  be  selected  and  trained. 
DMRS  -  Defense  Mobility  Requirements  Study 
DoD  Directive  5000.1  (March  15.  1996)  -  States  policies  and  principles  for  all  DoD  acquisition  programs  and 

identifies  the  Department's  key  acquisition  officials  and  forums,  with  supporting  documents  (DoD  5000  2-R) 

it  provides  mandatory  procedures  for  major  defense  acquisition  programs  and  major  automated  information 

system. 
DT&E  -  Development  Test  and  Evaluation.  T&E  conducted  to  measure  progress,  usually  of 

components/subsystems,  and  to  assist  the  engineering  design  and  development  process  and  verify  attainment 

of  technical  performance  specifications  and  objectives    Usually  conducted  under  controlled  or  laboratory 

conditions.  Can  be  conducted  before  or  after  production  begins. 
DWL  -  Designed  Water  Line 
DYNAMO  -  System  Dynamics  modeling  software 
Engineering  Change  Proposal  (ECP)  -  a  proposal  to  the  responsible  authority  recommending  that  a  change  to  an 

original  item  of  equipment  be  considered  and  the  design  or  engineering  change  be  incorporated  into  the 

article  to  modify,  add  to.  delete  or  supersede  original  parts. 
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Federal  Acquisition  Reform  Act  (FARA)  -  cited  as  the  Federal  Acquisition  Reform  Act  of  1995,  requires 

government  construction  projects  to  follow  a  two  phase  contracting  approach;  phase  1  will  define  technical 
requirements,  approaches  and  evaluation  procedures  (but  not  detailed  design  specifications  or  cost  ceilings) 
for  open  contract  competition;  phase  2  will  award  a  contract  based  on  the  evaluation  procedures  delineated  in 
phase  1. 

Federal  Acquisition  Streamlining  Act  (FAS A)  -  cited  as  the  "Federal  Acquisition  Streamlining  Act  of  1994",  the  act 
allows  government  agents  to  negotiate  limited  contracts  (by  amount,  duration  and  scope)  without  the 
requirements  of  open  competition  and  contract  bidding. 

Functional  Configuration  Audit  (FCA)  -  the  formal  examination  of  functional  characteristics  test  data  for 

configuration  item,  prior  to  acceptance,  to  verify  that  the  item  has  achieved  the  performance  specified  in  its 
functional  or  allocated  configuration  identification. 

Functional  analysis  and  allocation  -  The  decomposition  of  each  of  the  top-level  functions  to  sub-functions  to  the 
point  that  each  sub-function  can  be  related  to  the  elements  of  a  physical  hierarchy,  the  allocation  of  the  top- 
level  performance  requirements  and  design  constraints  to  the  functions  and  sub-functions,  and  the  capture  of 
the  aggregation  in  a  functional  architecture. 

Functional  architecture  -  The  hierarchical  arrangement  of  functions  and  their  decomposition  to  sub-functions  and  the 
allocation  of  the  top  level  performance  requirements  and  design  constraints  to  functions  and  sub-functions. 

Functional  baseline  -  The  initially  approved  documentation  describing  a  system's  top  level  functional  and 

performance  requirements  and  design  constraints  and  all  changes  thereto.  The  functional  baseline  can  be 
changed  only  with  Government  approval.  The  functional  baseline  is  usually  initially  approved  near  the  end 
of  the  Program  Definition  and  Risk  Reduction  Phase,  as  part  of  the  procurement  process  for  Engineering  and 
Manufacturing  Development. 

Hull.  Mechanical  &  Electrical  (HM&E)  -  The  totality  of  non-payload  (typically  combat  systems)  ship  systems  and 
components. 

FTVAC  -  Heating.  Ventilation  and  Air  Conditioning 

Integrated  Logistics  Support  (ILS)  -  A  disciplined,  unified,  and  iterative  approach  to  the  management  and  technical 
activities  necessary  to  (1)  integrate  support  considerations  into  system  and  component  design;  (2)  develop 
support  requirements  that  are  consistently  related  to  readiness  objectives,  to  design,  and  to  each  other; 
(3)  acquire  the  required  support;  and  (4)  provide  the  required  support  during  the  operational  phase  at 
minimum  cost. 

Integrated  Management  Plan  (IMP)  -  A  contractual  description  of  the  applicable  documents,  significant 

accomplishments,  accomplishment  criteria,  events,  and  critical  processes  necessary  to  satisfy  all  contract 
requirements.  The  completion  of  each  significant  accomplishment  is  determined  by  measurable 
accomplishment  criteria.  The  significant  accomplishments  have  a  logical  relationship  to  each  other  and,  in 
subsets,  lead  up  to  events.  Each  Event  is.  in  turn,  complete  when  the  significant  accomplishments  leading  up 
to  it  are  complete.  The  critical  processes  are  described  by  narratives  that  include  Objectives,  Governing 
Documentation,  and  an  Approach.  The  IMP  includes  an  indexing  scheme  (sometimes  called  a  single 
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numbering  system)  that  links  each  significant  accomplishment  to  the  associated  CWBS  clement,  event. 

significant  accomplishment  criteria,  and  tasks  presented  in  the  Integrated  Master  Schedule  (IMS).  The  data  in 

the  IMP  defines  the  necessary  accomplishments  for  each  event  both  for  each  IPT  and  for  the  contract  as  a 

whole 
Integrated  Master  Schedule  (IMS)  -  The  schedule  showing  the  time  (calendar)  relationship  between  significant 

accomplishments,  events,  and  the  detailed  tasks  (or  work  packages)  required  to  complete  the  contract.  The 

IMS  uses  (and  extends  if  necessary)  the  same  indexing  (or  single  numbering  system)  as  used  in  the  Integrated 

Master  Plan  (IMP). 
Integrated  Product  and  Process  Development  (IPPD)  -  A  management  technique  that  simultaneously  integrates  all 

essential  acquisition  activities  through  the  use  of  multi-disciplinaiy  Integrated  Product  or  Process  Teams 

(IPTs).  Specifically  defined  m  the  DOD  Guide  to  Integrated  Product  and  Process  Development,  5  Feb  96. 
Integrated  Product  Team  (IPT)  -  Team  composed  of  specialists  from  all  applicable  functional  disciplines  working 

together  (1)  to  deliver  products  and  processes  that  affordably  meet  all  requirements  at  acceptable  risk  and 

(2)  to  enable  decision  makers  to  make  the  right  decisions  at  the  right  time  by  timely  achievement  of  the 

significant  accomplishments  in  the  Integrated  Master  Plan  (IMP). 
IPS  -  Integrated  Program  Summary,  a  DOD  Component  document  prepared  and  submitted  to  the  milestone  decision 

authority  in  support  of  Milestone  I,  II.  Ill  and  IV  reviews.  It  provides  an  independent  assessment  of  a 

program's  status  and  readiness  to  proceed  into  the  next  phase  of  the  acquisition  cycle. 
Interface  requirement  -  The  functional  and  physical  design  constraints  imposed  on  each  other  by  two  or  more 

functions,  items,  or  systems  or  between  a  system  and  a  facility.  Functional  interfaces  include  signal. 

electrical,  electromagnetic,  and  software.  Physical  interfaces  include  keep-out  volumes  and  mating  surfaces 

and  connections. 
Interface  -  The  boundary,  physical  or  conceptual,  between  two  or  more  functions,  systems,  or  items  or  between  a 

system  and  a  facility  at  which  interface  requirements  are  set 
IOC  -  Imtial  Operational  Capability,  the  first  attainment  of  the  minimum  capability  to  effectively  employ  a  weapon, 

item  or  equipment,  or  system  of  approved  specific  characteristics,  and  which  is  manned  or  operated  by  an 

adequately  trained,  equipped,  and  supported  military  umt  or  force. 
JIT  -  Just  In  Time,  a  "pull"  system,  driven  by  actual  demand  Goal  is  to  produce  or  provide  one  part  just-in-time  for 

the  next  operation.  Reduces  stock  inventories,  but  leaves  no  room  for  schedule  error   As  much  a  managerial 

philosophy  as  it  is  an  inventory  system. 
LBP  -  Length  between  Perpendiculars  -  usually  the  length  of  the  ship  at  the  waterline 
Legacy  system  -  A  system/subsystem/component  associated  with  or  envisioned  for  a  DOD  application,  that  exists  or 

can  be  anticipated  to  exist  in  a  time  frame  that  supports  its  inclusion  as  part  of  a  design  being  developed  to 

met  a  current  requirement. 
LFT&E  -  Live  Fire  Test  &  Evaluation,  survivability  testing  and  lethality  testing  required  before  full-scale 

production.  Must  be  conducted  (unless  a  waiver  is  approved  by  the  USD(A))  on  ACAT  I  and  II  programs 

for: 
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a.  a  covered  system  (a  vehicle,  weapons  platform,  or  conventional  weapon  system  designed  to  provide  some 
degree  of  protection  to  the  user  in  combat, 

b.  a  major  munitions  or  missile  program  or 

c.  a  product  improvement  program  that  will  significantly  affect  the  survivability  of  a  covered  system. 

Life  Cycle  Cost  (LCC)  -  Life  cycle  costs  include  all  Research  and  Development,  Procurement,  and  Operation  and 
Support  costs  from  program  inception  to  disposal  of  the  last  associated  end  item.  The  minimum  categories  of 
cost,  which  shall  be  used  to  estimate  life  cycle  cost,  are  as  follows: 
Research  and  Development  Costs:  Includes  all  costs  associated  with  conceptual/feasibility  studies,  basic 

research,  advanced  research  and  development,  engineering  design,  fabrication  and  test  of  engineering 
prototype  models  (hardware),  and  associated  documentation.  These  costs  are  generally  non-recurring. 
Procurement  Costs:  Includes  all  costs  associated  with  the  acquisition  of  systems/equipment  (once  the 
Research  and  Development  has  been  completed).  The  following  subcategories  apply: 
Construction  Cost:  Includes  all  facility  construction,  capital  equipment  and  facility  maintenance. 
Manufacturing  Cost:  Includes  all  recurring  and  non-recurring  costs  associated  with  the  production  and 

test  of  multiple  quantities  of  prime  systems/equipment. 
Non-Recurring  Manufacturing  Cost:  Includes  all  fixed,  non-recurring  costs  associated  with  the 
production  and  test  of  operational  systems/equipment,  such  as  manufacturing  management, 
manufacturing  engineering,  initial  factory  tooling  and  test  equipment,  quality  assurance,  first 
article  qualification  test  (reliability  test,  maintainability  demonstration,  support  equipment 
compatibility,  technical  data  verification,  personnel  test  and  evaluation,  interchangeability.  and 
environmental  test)  and  related  support,  production  sampling  tests  and  related  support. 
Recurring  Manufacturing  Cost:  Includes  all  recurring  end  item  production  costs  such  as  fabrication, 
subassembly  and  assembly,  material  and  inventory  control,  inspection  and  test,  and  packaging 
and  shipping.  Sustaining  engineering  support  required  on  a  recurring  basis  is  also  included. 
Initial  Logistics  Support  Costs:  Includes  operational  test  and  support  equipment,  training  equipment 
and  spare/repair  parts  material  costs. 
Operation  and  Support  Costs:  Includes  all  costs  associated  with  operating  and  maintaining  the  system  after 
delivery.  The  following  subcategories  apply: 
Mission  Personnel:  The  costs  of  all  pay  and  allowances  for  military  personnel  required  operating  the 

end  item. 
Unit  Level  Consumption:  The  cost  of  fuel,  repair  parts  and  supplies,  depot-level  rcpanables.  training 
munitions  and  expendable  stores,  purchased  services  and  the  cost  of  temporarily  assigned 
personnel. 
Intermediate  Maintenance:  The  cost  of  maintenance  and  repair  actions  performed  by  tenders  and 

shore-based  intermediate  maintenance  activities. 
Depot  Maintenance:  The  cost  of  ship  overhauls  and  the  installation  costs  of  performing  slup 
modifications  (fleet  modernization). 
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Sustaining  Support:  The  cost  of  centrally  provided  material  (equipment  associated  with  ship 

modifications),  sustaining  engineering  support,  software  maintenance  and  any  other  require 
sustaining  support. 
Indirect  Support:  The  cost  of  system  specific  training,  permanent  change  of  station  and  medical  care. 
System  Phase-Out  and  Disposal:  The  cost  of  condemning  or  disposing  of  an  item. 
LOA  -  Length  over  All  -  Total  length  of  the  ship 
LSI  -  Lean  Ship  Initiative 
Margin  -  Reserve  for  future  growth 
MARITECH  -  Marine  Systems  Technology 
MILSPEC  -  Military  Specifications 

Molecules  -  System  Dynamics  Building  Blocks  generated  by  Jim  Hines  for  Vensim  and  15.875 
NAVSEA  -  Naval  Sea  Systems  Command 
NAVSHPSSO  -  NAVSEA  Shipbuilding  Support  Office 
Non-Developmental  Item  (NDI)  -  Any  item  that  is 

(1)  available  in  the  commercial  marketplace  or 

(2)  previously  developed  and  in  use  by  a  department  or  agency  of  the  United  States,  a  State  or  local 
Government,  or  a  foreign  Government  with  which  the  United  States  has  a  mutual  defense  cooperation 
agreement  and  that  does  not  require  unique  upgrades  or  maintenance  over  its  life-cycle  to  meet  the 
current  requirements.  • 

In  some  cases  NDI  may  be  extended  to  include  items  that 

(a)  have  been  developed  but  are  not  yet  available  m  the  commercial  marketplace  or  in  use  by  a  Government 
entity  or 

(b)  require  only  minor  modification  or  upgrade. 

Open  system:  A  system  architecture  winch  uses  a  generally  accepted  set  of  industry  standards  to  define  system 
interfaces  such  that  components  or  subsystems  can  be  readily  substituted  or  upgraded. 

Operating  and  support  costs:  see  Life  Cycle  Cost 

OT&E  -  Operational  Test  and  Evaluation,  the  field  test,  under  realistic  conditions,  of  any  item  (or  key  component) 
or  weapons,  equipment,  or  munitions  for  the  purpose  of  determining  the  effectiveness  and  suitability  of  the 
weapons,  equipment,  or  munitions  for  use  in  combat  by  typical  military  users;  and  the  evaluation  of  the 
results  of  such  tests 

PCA  -  Physical  Configuration  Audit,  physical  examination  to  verify  that  the  configuration  item(s)  "as  built" 
conforms  to  the  technical  documentation  which  defines  the  item.  Approval  by  the  government  program 
office  of  the  CI  product  specification  and  satisfactory  completion  of  this  audit  establishes  the  product 
baseline.  May  be  conducted  on  first  full  production  or  fist  LRTP  item 

PDR  -  Preliminary  Design  Review,  review  conducted  to  ascertain  if  the  preliminary  design  is  to  be  committed  to 
detailed  design.  Conducted  for  each  configuration  item  to  evaluate  the  progress,  technical  adequacy  and  risk 
resolution  of  the  selected  design  approach,  to  determine  its  compatibility  with  performance  and  engineering 
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requirements  of  the  development  specification;  and  to  establish  the  existence  and  compatibility  of  the 
physical  and  functional  interfaces  among  the  item  and  other  items  of  equipment,  facilities,  computer 
programs  and  personnel. 

PERT  -  Probabilistic  Evaluation  and  Review  Technique 

Phase  -  Period  of  time  that  corresponds  to  one  of  the  four  primary  phases  of  engineering  and  design.  The  phases 

include  Concept  Design  Phase,  Preliminary  Design  Phase,  Contract  Design  Phase  and  Detailed  Design  Phase. 

Physical  architecture  -  The  physical  hierarchy  and  the  functional  requirements  and  design  constraints  for  each 

element  in  the  hierarchy.  It  can  be  viewed  as  an  intermediate  step  between  the  functional  architecture  and  the 
physical  hierarchy,  on  the  one  hand  and  the  allocated  baseline,  on  the  other  hand. 

Procurement  cost  -  see  Life  Cycle  Cost 

Product  hierarchy,  physical  hierarchy  -  The  hierarchical  arrangement  of  products,  processes,  personnel  skill  levels, 
and  manpower  levels  that  satisfy  the  functional  baseline.  The  top  entry  in  the  hierarchy  is  the  system.  The 
hierarchy  extends  to  include  all  components  and  computer  software  units  necessary  to  satisfy  the  functional 
baseline  whether  deliverable  or  not.  It  includes  the  prime  operational  hardware  and  software.  Contractor- 
supplied  support  equipment.  Government-inventory  support  equipment,  technical  manuals,  training  programs 
for  both  Government  and  Contractor  personnel.  Government  personnel  skill  and  manpower  levels,  spare  parts 
requirements,  and  factory  support  equipment  and  tooling  which  collectively  result  in  the  system  that  satisfies 
the  functional  baseline. 

PRR  -  Production  Readiness  Review,  a  formal  examination  of  a  program  to  determine  if  the  design  is  ready  for 
production,  production  engineering  problems  have  been  resolved,  and  the  producer  has  accomplished 
adequate  planning  for  the  production  phase. 

PWBS  -  Product  Work  Breakdown  Structure 

QA  -  Quality  Assurance 

Requirements:  Characteristics,  attributes,  or  distinguishing  features  that  a  system  or  system  element  must  have 
within  a  stated  environment  or  set  of  conditions  in  order  to  meet  an  operational  need  and  comply  with 
applicable  policy  and  practices. 

Risk  management  -  A  documented  process  for  the  prospective  (looking  ahead)  and  recurring  identification  of  what 
can  go  wrong,  assigning  a  level  of  risk  (e.g..  High,  Moderate.  Low)  to  each  risk,  and  planning  and 
implementing  mitigation  steps  for  each  commensurate  with  the  level  of  risk 

Risk  -  A  measure  of  the  uncertainty  of  attaining  a  goal,  objective,  or  requirement  and  the  consequences  of  not 
attaining  it.  The  uncertainty  is  the  result  of  one  or  more  undesirable  Events  that  could  occur  during  the 
system  life  cycle  for  which  insufficient  resources  and  time  are  programmed  to  overcome  them.  The 
consequences  are  inability  to  satisfy'  the  operational  military  need  and  exceeding  the  programmed  budget  and 
directed  schedule. 

RRF  -  Ready  Reserve  Force 

SA'AR  -  Corvette  sized  combatant  built  by  Ingalls  for  Israeli  Navy. 

SC-2 1  -  Next  combatant  ship  program  after  DDG-5 1 ,  also  designated  DD-2 1 . 
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Scaleablc  -  An  attribute  of  design;  develop  designs,  architectures,  systems  and  transitions  technologies  that  era 
adaptable  across  a  range  of  end  items  (such  as  ship  classes). 

SCP  -  System  Concept  Paper,  OBSOLETE,  has  been  superceded  by  Integrated  Program  Summary  (IPS) 

Selected  Acquisition  Report  (SAR)  -  report  of  program  progress  presented  to  congress  for  budgetary  oversight. 

SEMP  -  System  Engineering  Management  Plan,  includes  plans  for  verification,  risk  alleviation,  analyses  and 
simulation  of  the  system  requirements. 

Ship  Production  Model  -  A  virtual  representation  of  a  particular  ship  being  built  at  a  shipyard 

Shipbuild  -  New  project  planning  and  progress  tracking  software  which  will  use  some  elements  of  System  Dynamics 

SFR  -  System  Functional  Review 

SHP  -  Shaft  Horse  Power 

Signature  -  Any  attribute  of  any  object  by  which  a  sensor  can  detect,  locate  and/or  classify  that  object. 

Significant  accomplishment  criteria  -  Specific,  measurable  conditions  that  must  be  satisfactorily  demonstrated 

before  a  significant  accomplishment  listed  in  an  Integrated  Master  Plan  (IMP)  is  complete  and  before  work 
dependent  on  the  accomplishment  can  proceed. 

Significant  accomplishment  -  A  specified  step  or  result  that  indicates  a  level  of  progress  toward  completing  an  event 
and,  in  turn,  meeting  the  objectives  and  requirements  of  the  contract. 

Simulation  -  The  process  of  conducting  experiments  with  a  model  (an  abstraction  or  simplification)  of  an  item 
and/or  part  or  all  of  its  operating  environment  for  the  purpose  of  assessing  its  behavior  under  selected 
conditions  or  of  evaluating  various  strategies  for  its  operation  within  the  limits  imposed  by  developmental  or 
operational  criteria.  Simulation  may  include  the  use  of  analog  or  digital  devices,  laboratory  models,  or  "test 
bed"  sites.  Simulations  are  usually  programmed  for  solution  on  a  computer,  however,  in  the  broadest  sense, 
military  exercises  and  war  games  are  also  simulations 

Specification  tree  -  The  hierarchical  depiction  of  all  the  specifications  needed  to  formally  control  the  development, 
procurement,  manufacture,  integration,  verification,  and/or  reprocurement  during  any  part  of  the  life  cycle. 

SSR  -  Systems  Requirement  Review,  conducted  to  ascertain  progress  in  defining  system  technical  requirements. 

Determines  the  direction  and  progress  of  the  systems  engineering  effort  and  the  degree  of  convergence  upon  a 
balanced  and  complete  configuration.  Normally  held  during  the  CE/D  phase,  may  be  repeated  after  start  of 
D/V  to  clarify  the  contractor's  understanding  of  redefined/new  user  requirements. 

STAR  -  System  Threat  Assessment  Report.  Documents  the  authoritative  threat  assessment  tailored  for  and  focused 
on  a  particular  US  defense  acquisition  program.  Prepared  by  the  Service  intelligence  agency  and  validated  by 
DIA  at  milestones  I,  II.  Ill  &  IV.  Applicable  to  all  threat  driven  defense  acquisition  programs.  Must  be 
system  specific  threat  oriented. 

Stealth  -  Ability  to  evade  radar 

Supportability  -  The  degree  to  which  planned  logistics  support  (including  system  design;  test,  measurement,  and 
diagnostic  equipment;  spares  and  repair  parts;  technical  data;  support  and  facilities;  transportation 
requirements;  training;  manpower;  and  software  support)  allow  meeting  system  availability  and  wartime 
usage  requirements. 
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SUPSHIP  -  Supervisor  of  Shipbuilding 

Survivability  -  The  capability  of  a  system  to  avoid  or  withstand  man-made  hostile  environments  without  suffering  an 

abortive  impairment  of  its  ability  to  accomplish  its  designated  mission. 
Sustainability  -  To  prolong  performance  over  a  period  of  time. 

System  Dynamics  -  Methodology  used  to  examine  complex  problems  with  non-linear  relationships  and  feedback 
System  engineering  -  A  process,  applied  iteratively  throughout  the  System  life  cycle  to  translate  stated  objectives 

into  design  requirements,  providing  an  integrated  solution  consisting  of  people,  products  and  processes  with 

the  capability  to  satisfy  the  customer  needs. 
System  -  The  entity  to  be  designed  as  defined  by  the  work  breakdown  structure.  The  entity  for  DD  2 1  Systems 

includes  the  ship  and  the  infrastructure  that  supports  ship  operation,  maintenance,  readiness,  etc. 
Technical  Performance  Measure  (TPM)  -  A  parameter  that  is  related  to  progress  toward  meeting  the  program  or 

contract  functional  requirements  or  goals  and  is  assessed  periodically  and  at  certain  events  to  estimate  the 

degree  to  which  the  final  value  will  meet  the  anticipated  or  required  level. 
TEMP  -  Test  and  Evaluation  Master  Plan,  an  overall  test  and  evaluation  plan,  designed  to  identify  and  integrate 

objectives,  responsibilities,  resources,  and  schedules  for  all  test  and  evaluation  to  be  accomplished  prior  to  the 

subsequent  key  decision  points.  Prepared,  as  early  as  possible  in  the  acquisition  process,  it  is  updated  as 

development  progresses. 
Total  Ownership  Costs  (TOC)  -  All  the  components  of  traditional  Life  Cycle  Cost  plus  so-called  linked,  indirect 

costs  (the  fraction  of  supporting  facilities/systems  developed  to  support  the  given  system. ) 
Traceability  -  The  ability  to  relate  an  element  of  the  functional  baseline,  functional  architecture,  physical  hierarchy, 

allocated  baseline,  design  baseline,  and  product  baseline  (or  their  representation  in  the  decision  data  base)  to 

any  other  element  to  which  it  has  a  master-subordinate  (or  parent  -child)  relationship. 
Trade  studies  -:  An  objective  comparison  with  respect  to  performance,  cost,  schedule,  risk,  and  all  other  reasonable 

criteria  of  all  realistic  alternative  requirements;  architectures;  baselines;  or  design,  verification. 

manufacturing,  deployment,  training,  operations,  support,  or  disposal  approaches. 
Upgrade  -  A  change  from  previously  delivered  items  because  of  obsolescence  of  a  part;  a  change  in  the  military 

need  or  threat;  an  operational,  supportability.  or  training  deficiency  is  identified;  the  system  life  must  be 

extended;  a  change  in  the  law  occurs;  or  an  unsafe  condition  is  detected. 
Vensim  -  System  Dynamics  modeling  software 
W1P  -  Work  In  Progress 
Work  Breakdown  Structure  (WBS)  -  A  product-oriented  hierarchical  tree  composed  of  the  hardware,  software. 

services  (including  cross-product  tasks  such  as  systems  engineering),  data,  and  facilities  that  encompass  all 

work  to  be  earned  out  under  the  program  or  contract  along  with  a  dictionary  of  the  entries  in  the  tree.  The 

WBS  for  the  entire  program  is  called  the  Program  or  Project  WBS  (PWBS).  The  WBS  for  the  work  under  the 

contract  is  called  the  Contract  WBS  (CWBS)  and  is  prepared  in  accordance  with  the  contract. 
Zones  -  Defines  what  functions  are  carried  out  in  tins  portion  of  the  ship  e.g.  Machinery.  Living.  Storage 
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8.4       Design  Task,  Discipline  and  Duration  Resources 

A  vast  quantity  of  material  was  analyzed  to  provide  both  general  and  specific  data  supporting  the  naval  ship 
design  process  model.  To  specifically  callout  these  references  at  each  instance  of  assessment  (Chapters  4  and  5) 
would  be  inappropriate.  Therefore,  the  following  list  and  brief  descriptions  of  reference  materials  will  be  given  to 
provide  the  reader  with  knowledge  of  those  resources: 

•  Andy  Summers.  Contract  Design  History  for  the  Guided  Missile  Destroyer  (PPG  3 1  Class).  Naval  Sea  Systems 
Command.  Washington  DC.  June  1987.  Contains  contract  design  schedules,  listings  of  resources  (budgetary 
and  personnel),  listings  of  design  products,  descriptions  of  design  processes  and  technical  results. 

•  Andy  Summers,  DDG-5 1  Guided  Missile  Destroyer  Preliminary  Design  History,  Naval  Sea  Systems  Command 
Washington  DC,  June  1984.  Contains  preliminary  design  schedules,  listings  of  resources  (budgetary  and 
personnel),  listings  of  design  products,  descriptions  of  design  processes  and  technical  results. 

•  Barry  Tibbitts,  "Why  Ships  are  Different",  John  J.  McMullen  Assoc,  1991.  General  description  of  design 
spiral  elements  and  practical  aspects  of  naval  system  engineering. 

•  Brown  and  Welsh,  "FF1 3  A  Ship  Design  Math  Model",  Massachusetts  Institute  of  Technology  course 
Applications  of  Naval  System  Design.  Fall  1996.  A  MathCAD  model  using  parametrics  to  develop  a  balanced 
surface  combatant  design,  model  demonstrates  physical  and  empirical  relationships  relative  to  the  design 
process. 

•  C.R.  Lloyd.  Design  Processes  for  the  AEGIS  Destroyer  Program,  Presentation  by  Bath  Iron  Works  (BIW). 
November  18,  1997.  Discussion  of  detailed  design  process,  team  structure  and  design  products  supporting  the 
lead  ship  and  manufacturing  design  of  the  DDG-5 1  class  surface  combatant. 

•  Doug  Hilton.  "PME  IDEF  Model",  Naval  Sea  Systems  Command.  September  13.  1994.  IDEF  description  of 
concept  and  preliminary  design  applicable  to  naval  design  using  the  Product  Model  Extension  (PME)  program. 

•  Edward  Lewis.  Principles  of  Naval  Architecture.  Society  of  Naval  Architects  and  Marine  Engmeers.  Jersey 
City,  NJ,  1988.  Detailed  descriptions  of  all  aspects  of  naval  ship  design  including  hydrostatics,  hydrodynamics, 
structural  analysis  and  design  integration 

•  Gale  and  Scott,  "Early  Stage  Ship  Design  Seminar".  Society  of  Naval  Architects  and  Marine  Engineers. 
October  1995.  Discussion  of  the  elements  of  the  design  spiral  for  concept  design  and  the  basic  relationships 
among  those  elements. 

•  Greg  Diggs,  MAAST  (Maritech  Agile  Shipbuilding  Toolkit),  Advanced  Marine  Enterprises  Inc..  March  26, 
1997,  hltp://\uvw\advmar.com/framework/splash.htm.  IDEF  descriptions  of  complete  design  process  for  a 
generic  "commercial"  ship  design. 

•  John  Dalton.  Implementation  of  Mandatory  Procedures  for  Major  and  Non-Major  Defense  Acquisition 
Programs  and  Major  and  Non-Major  Information  Technology  Acquisition  Programs  (SECNAVTNST  5000.2B). 
Department  of  the  Navy,  Washington  DC,  December  6,  1996.  Programmatic  requirements  relative  to  all  phases 
of  design  process  including  listing  of  those  design  and  risk  assessment  products  required  by  law.  statute  and 
direction. 
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John  Dalton.  Program  Decision  Process  (SECNAVINST  5420. 188E).  Department  of  the  Navy,  Washington 
DC,  October  31,  1995.  Programmatic  process  description  of  those  design  products  that  must  be  presented  at 
each  milestone  authorization. 

Karaszewski  and  Wade.  Infrastructure  Study  in  Shipbuilding  Report  on  Initial  Findings  Part  2,  IDEFo 
Diagrams  and  Glossary,  David  Taylor  Research  Center.  Bethesda.  MA.  January  3,  1991  IDEF  descriptions  of 
complete  design  process  for  a  generic  "commercial"  ship  design. 

Mahoney,  Welsh  and  Moton.  "13.412  DD13A  Feasibility  Design  Requirements",  Massachusetts  Institute  of 
Technology  course  Applications  of  Naval  System  Design,  Fall  1997.  Listing  of  design  products  required  for 
concept  and  feasibility  assessment  of  a  surface  combatant  design. 

Myron  Ricketts.  Manual  for  Naval  Surface  Ship  Design  Technical  Practices.  Naval  Sea  Systems  Command. 
Washington  DC,  1980.  Detailed  descriptions  of  all  design  phases,  all  design  products,  and  design  inter- 
relationships necessary  to  enable  individual  NAVSE A  engineers  understand  the  impacts  of  design  decisions  on 
other  design  elements. 

Naval  Surface  Warfare  Center  Carderock  Division,  "Getting  Started  &  Tutorials:  Advanced  Surface  Ship 
Evaluation  Tool  (ASSET)  Family  of  Ship  Design  Synthesis  Programs",  September  30,  1997.  Description  of  the 
ASSET  modules,  formulations  and  synthesis  structure. 

RADM  Roger  B.  Home,  "Concept  to  Commissioning.  Improving  the  Ship  Design.  Acquisition  and 
Construction  Process:  Strategic  Plan".  Naval  Sea  Systems  Command.  Washington,  DC.  June  1991.  Detailed 
analysis  of  naval  ship  design  process  including  statistical  assessment  of  design  timelines  and  costs,  interviews 
and  suggestions  from  design  participants,  and  design  organization  structures. 

Ron  Nix,  "T-AG9X  Preliminary /Contract  Design  Estimates",  Naval  Sea  Systems  Command,  January  16.  1987. 
Listing  of  design  products,  timelines  and  iterations  (presented  by  design  discipline  and  sub-discipline)  estimated 
for  an  auxiliary  ship. 

Scott  Ripley,  "Pre-Contract  Product  Development-Process  Flow  Chart".  Newport  News  Shipbuilding. 
December  1 1.  1996.  IDEF  diagram  for  all  processes  (engineering,  cost,  programmatic,  legal,  etc.)  related  to  the 
development  of  an  aircraft  earner. 

Ship  Design  Group,  Ship  Design  Project  Histories:  Volume  I.  II  and  III.  Naval  Sea  Systems  Command. 
September  1978.  May  1986  and  August  1996.  Complete  descriptions  of  concept  through  contract  design  for  all 
naval  ship  designs  developed  from  1970  through  1996.  Includes  manpower  allocation,  design  disciplines,  costs, 
ship  descriptions  and  timelines. 

Storch.  Hammon.  Bunch  and  Moore,  Ship  Production.  Society  of  Naval  Architects  and  Marine  Engineers. 
Jersey  City,  NJ.  1995.  Generic  description  of  design  products,  design  organization  and  production 
considerations  relative  to  general  ship  design. 
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8.5       Baseline  DDG-51  Task  and  Productivity  Levels 

The  following  data  has  been  extrapolated  from  the  references  in  Chapter  8.4  and  was  used  to  calibrate  the 
Naval  Ship  Design  Process  Model. 


Node 

Task  Element 

Average  ManMonths  Per  Task  (Adjusted  for  DDG-51  Program) 

Concept 

Preliminary 

Contract 

Detailed 

All 

Plans 

Construct 

1 

n 

Dl 

o 

0. 

Pro-am  Management  Tasks 

0  63 

1  18 

11  37 

9  65 

11  41 

6  85 

Requirements  &  Assessment 

021 

0  38 

5  86 

4  96 

5  84 

3  45 

Risk  Mitigation  &  Coordnabon 

0  07 

038 

3  96 

3  22 

3  90 

2  30 

c 

■ 
n 
c 
5> 
c 
u 

w 

E 

> 

Logshcs  and  Reliability 
Engineering 

1  02 

8  24 

11  72 

1681 

20  35 

11  63 

Design  Integration  & 
Specifications 

661 

7  36 

15  94 

1587 

17  93 

12  74 

Producibilrty  and  Production 
Engineering 

2  55 

21  28 

11  75 

17  63 

21  35 

14  91 

Performance-Requirements 
Assessment 

3  36 

5  57 

6  20 

7  12 

8  62 

618 

Manning 

1  69 

2  01 

2  06 

3  93 

4  76 

2  89 

c 
■c 

c 
a 
c 
ill 

5 
X 

Hull  Geometry 

1  97 

5  57 

1  97 

3  16 

3  32 

3  30 

Weight.  Hull  Subdivision  & 
Hydrostatic  Design 

1  96 

5  57 

0  19 

0  63 

0  76 

1  82 

Hydrodynamics-Resistance 

2  55 

5  57 

8  82 

11.35 

1351 

8  36 

Hydrodynamics-Seakeeping 

255 

557 

8  82 

11  35 

1351 

8  36 

Hydrodynamics-Maneuv«nng. 
Appendage  &  Propeller  Design 

2  55 

5  57 

1  26 

1  01 

1  22 

232 

Structures-Static  and  Dynamic 
Design 

0  61 

5  57 

1  25 

1  19 

1  44 

201 

Space  and  Arrangements 

1  27 

0  15 

2  29 

2  02 

2  20 

1  59 

i 

|   a 
w   c 

I! 

Machinery  Systems  Design  and 
Integration 

3  57 

5  86 

1.75 

503 

5  93 

4  43 

Propulsion  Systems 

0  77 

0  62 

1  38 

1  69 

205 

1.30 

Electncal  Systems 

077 

0  62 

1  38 

1  69 

2  05 

1  30 

Auxiliary  and  Support  Systems 

1.30 

084 

542 

5  06 

6  13 

3  75 

Deck.  Handling  and  Aircraft 
Support  Systems 

1.28 

1  47 

0  30 

1.57 

1.90 

1  30 

b 

c   £ 

O     Ol 

i 

Mission  Systems  Selection, 
Design  and  Integration 

3  56 

1  94 

1  81 

3  70 

4  48 

3  10 

Topside  Design  and  Integration 

13  02 

1  24 

2  60 

626 

7  58 

6  14 

o 
u 

Cost  Estimates  &  Analysis 

0.61 

1  02 

5  29 

4  23 

5.13 

3  26 

Totals  and  Averages 

2  37 

4  07 

4  93 

6  05 

7  21 

4  93 
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Node 

Task  Element 

Analysis  and  Approval  Periods  (workdays) 

Average  for  45  Programs  from  CNA  Study 

CG-*7                                  DDG-51 

NAVSEA 

PMO 

Review/Approval  Chain 

Review/Approval  Chain 

1 

CD 

Program  Management  Tasks 

36 

42  5 

46.3 

Requirements  &  Assessment 

64 

53  0 

76  3 

1000 

24  0 

Risk  furtigation  &  Coordination 

75 

1150 

1400 

0) 

c 
r 
a 
o 
c 

Logistics  and  Reliability 
Engtneenng 

Design  integration  & 
Specifications 

CD 
C 
Ui 

Produ ability  and  Production 
Engjneenng 

05 

15.0 
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Hull  Geometry 
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£     CD 

Propulsion  Systems 

f| 
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Deck.  Handling  and  Aircraft 
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§  » 

-    = 

Mission  Systems  Selection. 
Design  and  Integration 

c  £ 

o    en 

3    € 

1 

Topside  Design  and  Integration 

o 
u 

Cost  Estimates  &  Analysis 

94 

100 

35  0 

Totals  and  Averaqes 

52 
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33  3 
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8.6       Programmatic  Task  Development  and  Processing 
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Acquisition  Program  Baseline  (APE!)  OPNAV  Processing  Procedures 


Program  Manager  (PM) 
D  rails  APB 


I 


PM  Provides  Draft 
Copies  For  Review 


J 


Program  Requirements 
Officer  (RO)  Coordinates 
OPNAV  Review 

Resource 
Sponsor 

N4 

N  6/185/ 
86/37/88 

N81 

N80 

N091 

RO  Resolves 
Issues  Within  OPNAV 

Packages  &  Comments 
Returned  To  PM 


RO  and  PM 
R  esol  ve  I  ssues 


P  M  Provides  Smooth  Copy 
For  Sponsor  Endorsement 


Figure  63  Acquisition  Program  Baseline  (APB)  Processing  Procedures 
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ORD  REVIEW,  VALIDATION,  AND  APPROVAL  PROCESS 


PARALLEL  REVIEWS 


STEP  ' 


MILESTONE 
DECISION 
AUTHORITY 
(NOTES) 


JPD-JOINT  POTENTIAL 
DESIGNATOR 

^JOINT 

■  JOINT  INTEREST 

J  N[>fc  PENDENT 


SPONSOR 

-PREPARE  DRAFT  ORD  BASED  ON 

AOA  ANALYSIS 

AtWINSTERH'SACK 
-ASSIGN  SPCNSORPRJORITY 
-ENSURE  PERFORMANCE 
PATAME'ERS  MEET  MISSION  NEED 


(INITIATE  AOA  ANALYSIS 


SERVICES JPD  REVIEW  [rat, 

83  AND  OTHERS  AS  TOPICS 


SERVICE  ORD 


USA.  USAf  .USMC 
fSER^CEORD) 


INILAL RE vIEvV AND  COMMENT 

NGS1 

N095 


N9J  (g-JCtPEM^/1/) 


STEP  3 


(NO  Tc  2) 


SPONSOR 

-CONSOLIDATE  COMMENTS 
-PREPARE  SMOOTH  ORD 
-SIGN  &  FORWARD 

-FOR  POTENTIAL  ACAT  ID  COORDINATE 
VMTH  N310  FOR  JROC  8RIEF 
-R38fNOTE3) 


N81  REVIEW  AND  COMMENT 

-ADMINISTER  AND  TRACK 

-PRIORITIZE  NEED 

-FORWARDORD  TO  JROC  MD  OTHER  SERVK 

FORlNTEROPERAaUTYEVALUATION  AND 

JONT  ASSESSMENT 
-STAFF  SERVICE ORDsFOR  OPNAVJPD 

ASSESSMENT  rNCTE  2) 


l  iRDA)    I 

T_5_nJ 


/CERTIFICATION 


STEP  5 


[provide  advance  cop  y  roNSiij) 


NOTE 

0)  COPT  9 R0\*ED  FOR  INFORMATION 

CO  FOR  ORG*  tf.lTX  lOHT   WTFRESTNINS 

OB  NO  PROCEEDING  MNS- SERVICE 

HEASSESSJOINT  POTEWTA1.  APPUCAJ'QN 
f3  M8CHA*  RESOURCES  REQUIREMENTS 

REVIEW  BOARD  <R3q  i-jCETSaSREOURED 
«l  SeWAND  C*l  SYSTEM  RELAT ED  PROGRAMS 
£j  IJAJC  PROGPAMSUilTHUSMflSCAl. 

SPONSORSHIP 

ACAT  II.  II  IV-  N9EN0QK£E.T£HNACMCF0R 

APPROVAL 

ACAT  I  -  N9  ENDORSE.  THEN  ACWC  FOR 

appnovt* 
(pi  MILESTONE  (SeCBiONAUTWORn'yiMaa) 

•USD(ASn  FOR  ACAT  10 

•  ASH  (RO&f*  FOR  ACAT  C.  I 
SYSCOM/PEC/OflPM  FOR  ACAT  Hi  IV 
(7}  CNC^HIDAItSAHO  ^PROVES  FOR  NAV*. 

AMOFO*  *OC  WHEN  DELEGATED 


SPONSOR 

-COLLECT  ENDORSEMENTS  8 
FORWARD  TO  N8  1 

-FORWARD DRAFT  AP5  TO N81 


-VALIDATE  ORD 
-PRIORITIZE  ORD 

-APPROVE  ACAT  M.  Ill .IVORD 


SPONSOR 

FORWARD  APPR  CVED  ACAT  IC   I 
IIMVOROMDAiTMO-E  6i 
AFTFP  SERIN.:  ZED 


-ENDORSE  ACATIORD 
FWD  RECOMMENDATIONS  TO  CNO 

-RE  VIEW  JROC  BRIEF 


VCNOJVALJDATE  4 
APPROVE 

ACATIC.'D 
■If.:  :'jv''=  " 


val.  date  key 
performance 
parameters 
extracted 
from  ac  at  id  ord 


N81Q 
SERIALIZE  AMD 

ISSUE 


Figure  64  Operational  Requirements  Document  (ORD)  Review,  Validation  and  Approval  Process1 
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8.7       Naval  Ship  Design  Process  Model 

The  following  formulations  are  shown  in  the  format  of  Vensim  code.  For  electronic  copies  of  the  formulation, 
contact  the  author  at  tomkimlav@sprintmail.com. 

Contracted  Assign  Rate[Phase,Discipline]= 

Current  Phase[Phase]*MIN(Contractor  New  Assigmnents[Phase,Discipline]/Contractor  Assign  Period\ 

[Phase]. Contractors  Available[Phase. Discipline 
]/Contractor  Assign  Period[Phase]) 
~  Manpower/Month 

I 

Adjust  Rate[Phase]= 

0.4,0.3,0.3,1.1.0.7 

~  Dimensionless 


Adjusted  Desired  Manpower[Phase,Discipline]= 

Desired  Manpower[Phase. Discipline]  *Effect  of  Schedule  Gap  on  Desired  Manpower[Phase.\ 

Discipline] 
~  Manpower 


Effect  of  Schedule  Gap  on  Overtime[Phase.Discipline]= 

Effect  of  Schedule  Gap  on  Overtime  f(Schedule  Gap[Phase,Discipline]) 
~  Dimensionless 


Net  Contractors= 

SUM(Contractors  Phase[Phase!]) 
Manpower 


Effective  E.\penenced[Phase,Discipline]= 

Contractor  Experienced[Phase.Discipline]*Overtime[Phase.Discipline] 
-  Manpower 

Experienced  Contractor  times  assigned  overtime 


Maximum  Overtime= 
1.75 
~  Dimensionless 

Maximum  monthly  overtime  that  may  be  assigned  of  personnel 


Phase  Task  Change[Phase,Discipline]= 
Rescope  Rate[Phase,Discipline] 
Tasks/Month 


Effect  of  Approval  Phase  on  Desired  Manpower [Phase]= 

Effect  of  Approval  Phase  on  Desired  Manpower  f(Approval  Phase[Phase]) 
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Dimensionless 


Phase  Tasks[Phase.Discipline]=  INTEG  ( 

Phase  Task  ChangefPhase, Discipline], 

Initial  TasksfPhase.Discipline]) 
~  Tasks 


NAVSEA  Assign  Rate[Phase.Disciphne]= 

Current  Phase[Phase]*MIN(NAVSEA  New  Assignnients[Phase,Discipline]/NAVSEA  Assign  Period\ 
.NAVSEA  Available[Phase.Discipline]/NAVSEA  Assign  Period 

) 

~  Manpower/Month 

I 

Rescope  Rate[Phase,Discipline]= 

Current  Phase[Phase]*Rescope  Fraction[Phase]*MAX(O.Input)*Initial  Tasks[Phase.Discipline\ 
]/Approval  Period[Phase] 

~  Tasks/Month 

~  The  rate  of  design  rescope  by  the  DoN/DoD  is  indicator  that  the  phase  \ 

impacted  by  rescope  is  the  current  phase  (equals  1)  times  a  random  \ 
generation  of  desired  change  introduction  (input)  times  the  a  fraction  of  \ 
the  baseline  (initial)  tasks  involved  in  the  rescope  over  the  time  \ 
required  to  introduce  rescope  (a  period  concurrent  with  the  approval  \ 
period) 

I 

Net  Productivity  Rate[Phase.Discipline]= 

Adjust  Rate  [Phase  ]*Avg  Design  Rate[Phase.Disciplme]*EffectOfFatigueOnProducti\it>'[Phase\ 

,Discipline]*EffectOfScheduleGapOnProductivit>' 
[Phase, Discipline] *Effect  of  Personnel  Level  on  Productivity[Phase. Discipline] 
~  Tasks/(Manpower*Month) 

I 

Contractor  New  Released[Phase.Disciplme]= 

IF  THEN  ELSE(Current  Phase[Phase]=0. Contractor  New[Phase.Discipline]/Contractor  Release  Penod\ 
,MIN(Contractor  New  Desired  Release[Phase,Discipline]/Contractor  Release  Penod. Contractor 
New\ 

[Phase.DisciphneJ/Contractor  Release  Period)) 
~  Manpower/Month 

Effect  of  NAVSEA  Percent[Phase.Discipline]= 

Effect  of  NAVSEA  Percent  f(NAVSEA  Percentage[Phase]/NAVSEA  Participation  Desired  Percentage\ 

[Phase.Discipline]) 
~  Dimensionless 


NAVSEA  New  Release  Rate[Phase,Discipline]= 

IF  THEN  ELSE(Current  Phase[Phase]=O.NAVSEA  New[Phase.Disciphne]/NAVSEA  Release  Penod\ 
,MTN(NAVSEA  New  Desired  Release[Phase,Discipline]/NAVSEA  Release  PeriodNAVSEA 
New[\ 

Phase.Discipline]/NAVSEA  Release  Period)) 
~  Manpower/Month 
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~  Release  of  new  project  personnel  is  the  minimum  of  the  desired  release  and  \ 

the  release  constraint  (manning  over  tune  required  to  release  personnel) 
I 

Desired  Duration  [Phase] = 
18.8,10.16,6 
~  Month 

I 

Avg  Design  Rate[Concept.Discipline]= 

1.58,  4.8,  15.36,  0.98,  0.15,  0.39,  0.3,  0.59,  0.51,  0.51.  0.39,  0.39.  0.39,  1.64,  0.79\ 

,0.28,  1.3,  1.3,0.77,0.78,0.28 
,0.08,  1.64—1 
Avg  Design  Rate[Prehminary,Discipline]= 

0.85,  2.63,  2.63,  0.12,  0.14,  0.05,  0.18.  0.5,  0.18.  0.18,  0.18,  0.18.  0.18,  0.18,  6.83\ 
,0.17.  1.62,  1.62.  1.19.0.68. 
0.52.0.8,0.98—1 
Avg  Design  Rate[Contract. Disciplined 

0.09.  0.17,  0.25,  0.09,  0.06.  0.09.  0.16,  0.49.  0.51,  5.15.  0.11.  0.11.  0.8.  0.8.  0.44\ 
,0.57,0.72.0.72,0.18.  3.35,0.55 
,0.38.0.19—1 
Avg  Design  RatefLead  Ship.Discipline]= 

0.1.  0.2.  0.31,  0.06,  0.06,  0.06,  0. 14,  0.25.  0.32,  1.6.  0.09,  0.09,  0.99,  0.84.  0.5\ 
,0.2.0.59,0.59.0.2,0.64,0.27, 
0.16,0.24—1 
Avg  Design  Rate[Manufacturing,Discipline]= 

0.09,  0.17,  0.26,  0.05.  0.06,  0.05,  0.12.  0.21,  0.26,  1.32.  0.07,  0.07.  0.82.  0.69.  \ 
0.45,0.17.0.49,0.49,0.16.0.53. 
0.22,0.13.0.2 

~  Tasks/(Month*Manpo\ver) 

Baseline  Desired  Manning[Phase.Discipline]= 

Initial  Tasks[Phase.Discipline]/(Avg  Design  Rate[Phase. Discipline]  *Desired  Duration[\ 

Phase]) 
~  Manpower 

~  Baseline  Manning  Requirement  is  the  Number  of  Tasks  over  the  tasks  per  man  \ 

required  to  meet  the  desired  schedule 

Effect  of  Schedule  Gap  on  Overtime  f( 

[(0.0)-(10,2)],(0.1),(l.l),(2,l).(10,2)) 

~  Dimensionless 

~  For  schedule  gap  of  1  or  less\!\!\! 

Initial  Schedule  Projection[Concept]= 

Desired  Duration[Concept]  —  | 
Initial  Schedule  Projection[Prelirninary]= 

Desired  Duration[Concept]+Desired  Duration  [Preliminary]  —  | 
Initial  Schedule  Pr  ;jection[Contract]= 

Desired  Duration[Concept]+Desired  Duration[Preliminary]+Desired  DurationfContract]  — | 
Initial  Schedule  Projection[Lead  Ship]= 

Desired  Duration  [Concept] +Desired  Duration[Preliminary]+Desired  Duration[Contract]+Desired  Duration\ 
[Lead  Ship]  — | 
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Initial  Schedule  Projection[Manufacturing]= 

Desired  Duration[Concept]+Desired  Duration  [Preliminary] +Desired  Duration[Contract]+Desired  Duration\ 

[Lead  Ship]+Desired  Duration  [Manufacturing] 
~  Month 


Net  Desired  Manpower= 

SUM(Desired  Manpower  Phase  [Phase!]) 
~  Manpower 

NAVSEA  Participation  Adjusted  Percentage[Phase,Discipline]= 

NAVSEA  Participation  Desired  Percentage[Phase,Discipline]*Effect  of  NAVSEA  Percent [Phase\ 

.Discipline] 
~  Dimensionless 

~  The  desired  manning  level  of  NAVSEA  relative  to  Contractors 

I 

NAVSEA  Participation  Desired  Percentage[Phase.Discipline]= 

MTN(NAVSEA  Participation  Nominal  Percentage[Phase].NAVSEA  Participation  Nominal  Percentage\ 

[Phase]  *Effect  of  Approval  Phase  on  NAVSEA  Percent 
[Phase]  ^Effect  of  Available  Budget  on  NAVSEA  Percent  [Phase]) 
~  Dimensionless 


Total  Contractors  Assigned[Phase]= 

(SUM(EffectiveExpenenced[Phase,Discipline!])+SUM(EffectiveNew[Phase.Discipline!])\ 

)*  Current  Contract  Fee  [Phase] 
~  Manpower 

The  total  contractors  assigned  as  a  cost  is  the  sum  of  current  contractors  \ 

times  the  additional  percentage  charged  to  current  contracts  (10%  overhead  \ 

fee) 


NAVSEA  Percentage[Phase]= 

NAVSEA  Phase[Phase]/MAX(l,  NAVSEA  Phase[Phase]+Contractors  Phase[Phase]) 
~  Dimensionless 


NAVSEA  Experienced  Release  Rate[Phase,Discipline]= 

IF  THEN  ELSE(Current  Phase[Phase]=O.NAVSEA  Experienced[Phase,Discipline]/NAVSEA  Release 
Period\ 

.MTN(NAVSEA  Exp  Desired  Release[Phase.Discipline]/NAVSEA  Release  PeriodNAVSEA 
Experienced\ 

[Phase. Discipline 
]/NAVSEA  Release  Period)) 
~  Manpower//Month 

-  Release  of  experienced  personnel  is  the  minimum  of  the  desired  release  and  \ 

the  release  constraint  (manning  over  time  required  to  release  personnel) 
I 

Desired  Manpower[Phase,Discipline]= 

MAX(  DesiredAccomplishrngRate[Phase,Discipline]  /  (Avg  Design  Rate[Phase,Disciphne]\ 

*  Adjust  Rate[Phase]). Baseline  Desired  Mannmg[Phase,Discipline]) 
~  Manpower 

161 


Net  NAVSEA= 

SUM(NAVSEA  Phase  [Phase!]) 
~  Manpower 

Contractor  Expenence  Release  Rate[Phase.Discipline]= 

IF  THEN  ELSE(Current  Phase[Phase]=0.  Contractor  Experienced[Phase,Discipline]/Contractor  Release 
Period\ 

,MIN( Contractor  Exp  Desired  Release[Phase.Discipline]/Contractor  Release  Period, Contractor 
Experienced\ 

[Phase.Discipline] 
/Contractor  Release  Period)) 
~  Manpower/Month 

Schedule  Shift[Concept,Discipline]= 

(Indicated  Completion  Date[Concept.Disciphne]-Desired  Schedule[Concept.Discipline])\ 
/Time  to  Shift  Schedule  — | 
Schedule  Shift[Preliminary,Discipline]= 

MAX(Indicated  Completion  Date [Concept.Discipline] -Desired  Schedule[Concept.Discipline\ 

]. Indicated  Completion  Date[Preliminar\.Discipline]-Desired  Schedule[Preliminar\-.Discipline\ 
])/Time  to  Shift  Schedule  — | 
Schedule  Shift[Contract.Disciplme]= 

MAX(Indicated  Completion  Date[Concept.Discipline]-Desired  Schedule[Concept,Disciphne\ 

].MAX(Indicated  Completion  Date[Preliminary.Discipline]-Desired  Schedule[Preliminary\ 
.Disciphne], Indicated  Completion  Date 
[Contract.Discipline] -Desired  Schedule[Contract,Discipline]))/Timeto  Shift  Schedule\ 

Schedule  Shift[Lead  Ship,Discipline]= 

MAX(Indicated  Completion  Date[Concept.Disciphne] -Desired  Schedule[Concept.Discipline\ 

].MAX(Indicated  Completion  Date|Preliminary,Discipline]-Desired  Schedule [PreliminarvA 

.Discipline],MAX(Indicated  Completion  Date 
[Contract.Discipline] -Desired  Schedule[Contract.Discipline], Indicated  Completion  Date\ 

[Lead  Ship.Discipline] -Desired  Schedule[Lead  Ship,Discipline])))/Time  to  Shift  Schedule\ 

Schedule  Shift  [Manufacturmg.Discipline] = 

MAX(  Indicated  Completion  Date  [Concept.Discipline] -Desired  Schedule[Concept.Discipline\ 

].MAX(Indicated  Completion  Date[Preliminar>*.Discipline]-Desired  Schedule[Preliminary\ 

.Disciplme].MAX(Indicated  Completion  Date 
[Contract.Discipline] -Desired  Schedule[Contract.Disciplme].MAX(Indicated  Completion  Date\ 

[Lead  Ship.Discipline] -Desired  Schedule[Lead  Ship.Discipline]. Indicated  Completion  Date\ 

[Manufacturing.Discipline 
]-Desired  Schedule[Manufactunng,Discipline]))))/Time  to  Shift  Schedule 
~  Month/Month 

~  The  shift  of  design  schedule  is  the  indicated  completion  date  over  the  \ 

time  required  to  initiate  the  full  time  shift... note  that  each  phase  date  \ 

is  shift  by  preceding  phase  schedule  shifts  as  well 
I 

Percent  Phase  Complete[Phase]= 

Total  Approved  Tasks[Phase]/SUM(Phase  Tasks[Phase.Discipline!]) 

~  Dimensionless 

~  The  Percent  Completion  of  the  current  phase  is  the  ratio  of  the  total  \ 
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approved  tasks  to  the  total  phases  tasks  initially  required  to  be  done 


Current  Contract  Fee[Phase]= 

Percentage  of  RFP  Contracts  [Phase]  *1+(1  -Percentage  of  RFP  Contracts[Phase])*l.  1 

~  Dimensionless 

~  The  current  contract  fee  represents  the  effective  cost  of  contractors  as  a  \ 

function  of  those  contracted  at  RFP  rate  (100%  cost)  and  those  on  current  \ 
NAVSEA  contracts  (additional  10%  overhead  to  cost) 


Overtime[Phase,Discipline]= 

MIN(Maximum  Overtime.Effect  of  Schedule  Gap  on  Overtime[Phase.Discipline]*Overtime  f\ 

(Indicated  Overtime  Required[Phase.Discipline])) 
~  fraction 

~  The  current  assigned  overtime  is  the  maximum  of  maximum  overtime  to  assign  \ 

and  the  overtime  profile  (assignment  schedule)  for  a  given  indicated  \ 

overtime  requirement 
I 

Effect  of  NAVSEA  Percent  f( 

[(0,0)-(U)].(0.1),(0.5,l),(0.75.0.75).(1.0)) 

~  Dimensionless 


Effective  New  [Phase. Discipline] = 

Contractor  Ne\v[Phase.Discipline]*0\ertime[Phase.Discipline] 

~  Manpower 

~  New  Contractors  times  the  o\  ertime  assigned 


Prob  Disco\er\  by  Phase[Phase]= 

0.4,0.37,0.3,0.23,0.2 

~  Dimensionless 

The  probability  of  discovery  of  an  error  increases  for  each  phase  as  more  \ 
individuals  are  involved  with  the  project  and  increasing  detail  is  examined 


Prob  Defect  Discovery  [Phase.Discipline|= 

Effect  of  Errors  on  Discovery[Phase.Discipline]*Prob  Discovery  by  Phase[Phase] 

~  Tasks/Tasks 

~  Probability  of  Discovery  by  Design  Phase  times  the  changing  probability  of  \ 

discover.  (Effect  of  Errors  on  Discovery)  as  the  total  errors  for  the  \ 

current  phase  increases 


Comp  Rate  fTPhase, Disciplined 

MTN(WIP[Phase.Discipline;  Min  Comp  Period[Phase. Discipline]. Effective  Personnel  Level\ 

[Phase. Discipline]  *Net  Productivity  Rate 
[Phase.Discipline]) 
~  Tasks/Month 

~  Tlie  average  completion  rate  for  the  WIP  remaining  in  each  discipline  \ 

during  each  phase  is  the  lesser  of  time  limited  completion  (WTP/minimum  \ 

period  to  complete)  and  resource  limited  completion  (personnel  available  \ 

times  net  rate  of  productivity  per  person) 
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Review  Rate[Phase,Discipline]= 

Review  Phase[Phase]*Completed[Phase,Discipline]/Review  Period[Phase] 

~  Tasks/Month 

-  The  rate  of  NAVSEA  Review  of  Tasks  is  the  completed  tasks  over  the  time  \ 

required  to  review  a  task.  ..note  that  this  assumes  task  review  is  \ 
continuous  (more  likely  this  is  not  the  case. and  leads  to  the  \ 
possibility  of  draining  completed  tasks  prior  to  proper  iteration  through  \ 
the  feedback  matrix... 


Review  Ratio  Actual  [Phase] = 

(SUM(Completed[Pliase,Disciphne!])+SUNl(Approved[Phase,Discipline!])+SUM(Revie\v[Phase\ 

.Discipline !  ] ))/SUM(Iniual  Tasks[Phase.Discipline !  ] ) 
~  Dimensionless 

~  The  Ratio  of  total  tasks  available  for  or  already  approved  to  the  total  \ 

intial  tasks  is  the  total  of  tasks  released  at  review  and  those  residing  \ 

as  Approved  divided  by  the  initial  tasks... by  phase. 


Review  Ratio  Desired[Phase]= 
0.8.0.9,0.95,0.5,0.5 
~  Tasks/Tasks 


Review  Error  Rate  f[Phase,Discipline]= 

Adj  Prob  Defect[Phase.Discipline]*Prob  Defect  DiscoveiyfPhase. Discipline] *(Review[Phase\ 

,Discipline]/Time  to  Detect  Errors[Phase]) 
~  Tasks/Month 


Review  Phase  [Phase] = 

Review  Phase  Effect  f( Review  Ratio  Actual[Phase]/Review  Ratio  DesiredfPhase]) 
~  Dimensionless 

~  Tlie  approval  phase  is  active  ( 1 )  for  actual  to  desired  ratios  greater  than  \ 

1  and  inactive  (0)  for  ratios  less  than  1 


Review  Phase  Effect  f( 

[(0.0)-(2,l)],(0,0).(0.537764,0.0921053).(0.773414.0.25),(0.954683.0.820175),(l.l).(\ 
2.1)) 

~  Dimensionless 

~  The  approval  Phase  Effect  Function  compares  the  ratio  of  Approval  Ratio  \ 

Actual  to  Desired,  for  net  ratios  greater  than  1,  the  approval  phase  is  \ 
active  (1)  for  ratio  less  than  1  the  approval  phase  is  not  active  (0)\!\! 


Review  Phase  Net= 

SUM(Review  Phase  [Phase!]) 
~  Dimensionless 


Internal  Error  Rate  f]Phase.Discipline]= 

Adj  Prob  Defect  [Phase.  Discipline]*  Prob  Defect  Discovery  [Phase.Discipline]*(Completed\ 
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[Phase,Discipline]/Time  to  Detect  Errors  [Phase]) 
Tasks/Month 


EffectOfScheduleGapOnProductivity[Phase.Discipline]= 

EffectOfScheduleGapOnProductivitv  f(Schedule  GapfPhase.Discipline\ 

]) 
~  dmnl 


Adj  Prob  Defect[Phase.Discipline]= 

Prob  Defect  by  Phase  [Phase]*  Effect  of  Errors  on  Defects[Phase.Discipline] 
~  Tasks/Tasks 


NAVSEA  Experienced[Phase.Discipline]=  INTEG  ( 

NAVSEA  Experience  Gain  Rate[Phase.Discipline]-NAVSEA  Experienced  Release  Rate[Phase.\ 

Discipline], 

0) 
-  Manpower 

~  The  accumulation  of  NAVSEA  personnel  with  direct  experience  with  the  \ 

current  design  Project  is  0  plus  the  rate  of  experience  gain  less  the  \ 

release  rate  of  experienced  personnel  from  the  project 


NAVSEA  Available[Phase.Discipline]=  INTEG  ( 

NAVSEA  New  Release  Rate[Phase.Discipline]+NAVSEA  Experienced  Release  Rate[Phase.Disciphne\ 
]-NAVSEA  Assign  Rate[Phase.Discipline]. 
NAVSEA  Baseline  Personnel[Phase,Discipline]) 
~  Manpower 

I 

Effect  of  Errors  on  Defects[Phase.Discipline]= 

Effect  of  Errors  on  Defects  f(Errors  Discovered[Phase,Discipline]/Initial  Tasks[Phase\ 

.Discipline]) 
~  Dimensionless 


Effect  of  Errors  on  Defects  f( 

[(0,0)-(l,l)].(0,l).(0.001.0.9).(0.01.0.8).(0.1.0.5).(0.247734.0.0745614).(L0)) 
~  Dimensionless 


Effect  of  Errors  on  Discovery! Phase. Discipline ]= 

Effect  of  Errors  on  Discovery  f(Errors  Discovered[Phase.Discipline]/Initial  Tasks[Phase\ 

.Discipline]) 
~  Dimensionless 


NAVSEA  Experience  Gain  Rate[Phase. Discipline^ 

NAVSEA  New[Phase.Discipline]/NAVSEA  Experience  Gain  Penod[Phase] 

~  Manpower/Month 

~  The  rate  of  transfer  of  personnel  from  new  to  project  to  experienced  with  \ 

the  project  is  the  number  of  personnel  over  the  average  time  to  acquire  \ 

experience 
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Error  Discovery  Rate[Phase.Discipline]= 

Internal  Error  Rate[Phase.Discipline]+Review  Error  Rate[Phase.Discipline] 
~  Tasks/Month 


NAVSEA  New[Phase.Discipline]=  INTEG  ( 

NAVSEA  Assign  Rate[Phase.Discipline] -NAVSEA  Experience  Gain  Rate[Phase.Discipline]-NAVSEA 
New  Release  Rate\ 

[Phase.Discipline] 

0) 
~  Manpower 


Prob  Defect  bv  Phase  [Phase]= 
0.2.0.19,0.15,0.11.0.1 
~  Dimensionless 

~  Probability  of  a  defect  will  change  with  each  phase  due  to  increasing  \ 

individuals  and  detail 


Total  Errors  per  Phase[Phase]= 

SUM(Errors  Discovered[Phase,Discipline!]) 
~  Tasks 


Effect  of  Errors  on  Discover)'  f( 

[(0,0)-(l.l)],(0,l),(6.001,0.9).(0.01.0.8).(0.1,0.5),(0.5,0.1).(l,0)) 
~  Dimensionless 


Errors  Discovered[Phase.Discipline]=  INTEG  ( 
Error  Discovery  Rate[Phase.Discipline]. 

0) 
~  Tasks 


Indicated  Overtime  Required[Phase. Disciplined 

IF  THEN  ELSE(Personnel  Assigned[Phase,Discipline]<=O.Adjusted  Desired  Manpower[Phase\ 

,Disciphne]/Man.Adjusted  Desired  Manpower 
[Phase. Discipline]/Personnel  Assigned[Phase.Disciphne] ) 
~  Dimensionless 


Man= 


Manpower 

The  unit  for  a  single  person 


Effect  of  Personnel  Level  on  Productivity[Phase,Discipline]= 

Effect  of  Persomiel  Level  on  Productivity  f(Personnel  Assigned[Phase,Discipline]/Man\ 
) 
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Dimensionless 

Described  in  literature  as  "communication  overhead",  mcreased  levels  of  \ 

personnel  assigned  to  a  project  can  adversely  effect  productivity  from  the  \ 

standpoint  of  required  personnel  interaction,  and  down  time  for  meetings.  \ 

etc... 


Design  Spiral  Rate[Phase,Discipline]= 

Feedback  FracUonrPhase]*MIN(Completed[Phase,Discipline]/TIME  STEP,MAX(Comp  Rate[Phase\ 

,Al]*Design  Spiral  Matrix 
[A  1, Discipline 
j,MAX(Comp  Rate[Phase,A2J*Design  Spiral  Matrix[A2.Discipline],MAX(Comp  RaterPhase,A3\ 

]*Design  Spiral  Matrix[A3,Discipline].MAX(Comp  Rate 
[Phase.Bl]*Design  Spiral  Matrix[Bl, Discipline], MAX(Comp  Rate[Phase.B2]*Design  Spiral  Matrix\ 

[B2,Discipline].MAX(Comp  Rate[Phase,B3 

] 

*Design  Spiral  Matrix[B3,Discipline],MAX(CompRate[Phase.34]*Design  Spiral  Matrix[B4\ 

. Discipline], MAX(CompRate[Phase.B5]*Design  Spiral  Matnx 
[B5.Discipline].MAX(Comp  Rate[Phase.Cl]*Design  Spiral  Matrix[Cl.Discipline],MAX(CompRate\ 

[Phase.C2]*Design  Spiral  Matrix[C2.Disciphne 
],MAX(Comp  Rate[Phase.C3]*Design  Spiral  Matnx[C3.Disciphne],MAX:(Comp  Rate[Pliase,C4\ 

]*Design  Spiral  Matrix[C4,Disciphne].MAX(Comp  Rate 
[Phase.C5]*Design  Spiral  Matrix[C5. Discipline], MAX(Comp  Rate[Phase.C6]*Design  Spiral  Matrix\ 

[C6,Discipline],MAX(CompRate[Phase.C7 

] 

*  Design  Spiral  Matrix[C7.Discipline].MAX(CompRate[Phase.Dl]*Design  Spiral  Matrix[Dl\ 

. Discipline]. MAX(CompRate[Phase.D2]*Design  Sprral  Matnx 

[D2.Discipline],MAX(Comp  Rate[Phase,D3]*Design  Spiral  Matnx[D3.Discipline].MAX(Comp  Rate\ 
[Phase,D4]*Design  Spiral  Matrix[D4,Discipline 

],MAX(Comp  Rate[Phase,D5]*Design  Spiral  Matnx[D5,Discipline],MAX(Comp  Rate[Phase.El\ 
]*Design  Spiral  Matrix[El,Discipline],MAX(Comp  Rate 

[Phase.E2]*Design  Spiral  Matrix[E2. Discipline], Comp  Rate[Phase.Fl]*Design  Spiral  Matrix\ 
[Fl. Discipline]))))))))))))))))))))))) 

~  Tasks/Month 

~  Design  feedback  (due  to  concurrent  design  assumptions  inherent  to  the  \ 

Naval  Design  Process)  is  the  fraction  of  impacted  design  tasks  (Feedback  \ 
fraction)  times  the  minimum  of  completed  tasks  rate  constraint  (completed  \ 
over  design  phase  time  measure,  .one  month)  and  the  maximum  "work  \ 
interference"  rate  for  the  given  discipline  compared  to  the  other  22  \ 
disciplines  (Feedback  matrix  times  the  disciplines  completion  rate) 

I 

Effect  of  Personnel  Level  on  Productivitv  f( 

[(0.0)-(100,l)].(0,l).(25.6798.0'964912),(52.8701.0.894737).(80.0604.0.714912).(100.\ 

0.5)) 
~  Dimensionless 


Funding  Period= 
12 

~  Month 


Rescope  Fraction[Phase]= 
0.05 
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Dimensionless 


Current  Phase  [Phase] = 

Current  to  Future  Phase[Phase]*Current  to  Past  Phase  [Phase]  *Effect  of  Percent  Complete  on  Project  End\ 

[Phase] 
~  Dimensionless 

~  To  determine  if  a  design  phase  is  a  Current  Phase  (equals  1),  multiply  the  \ 

Current  to  Future  Phase  indicator  times  the  Current  to  Past  Phase  \ 

indicator... if  equals  0.  the  phase  is  not  yet  started  (Current  to  Future  \ 

Phase  is  0)  or  already  over  (Current  to  Phase  is  0) 
I 

Percent  Complete  at  Project  End[Phase]= 
0.8.0.9,0.9,0.95.0.95 

~  Dimensionless 


Effect  of  Percent  Complete  on  Project  End  f( 
[(0,0)-(U)],(0.1).(0.999,l),(l,0)) 

-  Dimensionless 


Effect  of  Percent  Complete  on  Project  End[Phase]= 

Effect  of  Percent  Complete  on  Project  End  f(Percent  Phase  Complete  [Phase] /Percent  Complete  at  Project 
End\ 

[Phase]) 

~  Dimensionless 


Internal  Error  Rate  [Phase,  Discipline] = 

Internal  Error  Rate  f[Phase.Discipline] 

~  Tasks/Month 

~  The  rate  of  internal  Q/A  and  defective  discovery  is  the  probability  of  a  \ 

defect  times  the  probability  of  discovering  the  defect  times  the  minimum  \ 
of  tasks  available  for  inspection  (completed  over  the  time  to  detect)  and  \ 
the  inspector  constraint  (QA  constraint) 


Max  Indicated  Completion  Date  [Phase] = 

Indicated  Completion  Date[Phase,Al] 
~  Month 


NAVSEA  Participation  Nominal  Percentage  [Phase] = 
0.3.0.2,0.2,0.1.0.1 
~  Dimensionless 

The  desired  manning  level  of  NAVSEA  relative  to  Contractors 


Personnel  Assigned[Phase.Discipline]= 

NAVSEA  New[Phase,Discipline]+Contractor  Ne\v[Phase,Discipline]+Contractor  Experienced\ 

[Phase.Discipline]+NAVSEA  Experienced 
[Phase.Discipline] 
~  Manpower 
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Total  personnel  (NAVSEA  and  Contracted,  novice  and  experienced  with  the  \ 
project)  assigned  to  each  discipline  during  a  given  time  of  each  design  \ 
phase 


Effect  of  Available  Budget  on  NAVSEA  Percent[Phase]= 

Effect  of  Available  Budget  on  NAVSEA  Percent  f(  Available  to  Desired  Budget  [Phase]) 
~  Dimensionless 


Approval  Phase  Net= 

SUM(Approval  Phase  [Phase!]) 
~  Dimensionless 


Planned  Annual  Funding[Phase]= 

3 .  2e+006, 1 .  5e+007, 1 .  62e+007,6. 44e+007,2 . 1 4e+007 
~  Dollars 

Initial  Values  determined  from  DDG-51  program  (NAVSEA  Ship  Design  \ 
Histories  and  Acquisition  Budget  results) 


GettingFatigued[Phase.Disciphne]= 

(Overtime[Phase.Discipline[  -  Fatigue[Phase,Discipline])  /  TimeToGetFatigued 
~  fraction  /  Month 


Net  Review[Phase]= 

SUM(Review[Phase.Discipline!]) 
~  Tasks 


Effect  of  Approval  Phase  on  Desired  Manpower  f( 
[(0.0)-(U)],(0,l).(1.0.5)) 
~  Dimensionless 


Effect  of  Approval  Phase  on  NAVSEA  Percent  [Phase] = 

Effect  of  Approval  Phase  on  NAVSEA  Percent  f( Approval  Phase[ Phase]) 
~  Dimensionless 


Effect  of  Approval  Phase  on  NAVSEA  Percent  f( 
[(0.0)-(U)].(0.1).(U.25)) 
~  Dimensionless 


Available  to  Desired  Budget  [Phase] = 

IF  THEN  ELSE(Perceived  Funding  Requirements[Phase]<=0.4.A\ailable  Budget [Phasej/Perceived 
Funding  Requirements\ 

[Phase]) 

~  Dimensionless 


Effect  of  Available  Budget  on  Contractors  f( 
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[(0.0)-(8.10)],(0.0).(0.5,0.2).(0.75,0.5),(1J).(2.4),(3.86707,6.71053),(6,8).(8,8)) 

~  Manpower 

~  For  available  budget  fractions  near  0  (available  is  low)  the  fraction  of  \ 

contractors  to  be  hired  is  directly  proportional... as  available  to  need  is  \ 
very  large,  more  contractors  will  be  hired  up  to  a  very  large  portion  \ 
(overfunding)  at  which  contractors  are  released\!\!\! 


Effective  Personnel  Level [Phase,Discipline]= 

(Contractor  Experienced[Phase,Discipline]*PDY  Contractor  Experienced  Factor+Contractor  New 
[Phase. Discipline] *PDY  Contractor  New  Factor+NAVSEA  Experienced[Phase.DisciplineJ*PDY 
NAVSEA  Experience  Factor\ 

+NAVSEA  New 
[Phase,Discipline]*PDY  NAVSEA  New  Factor)*Overtime[Phase.Disciphne] 
~  Manpower 

~  The  effective  personnel  level  is  the  sum  of  the  effective  number  of  \ 

personnel  assigned  (number  of  personnel  times  an  experience  factor) 


Overtime  f( 

[(0.0)-(2,2.6)],(0,l),(0.175258,l),(0.417526.1).(0.747423J),(l.l).(125,l).(1.5.1.2\ 

).(1.7.1.4).(1.8.1.6).(1.9.1.8),(2.2)) 
~  fraction 


Funding  Gap[Phase]= 

Perceived  Funding  Requirements  [Phase] -Available  Budget  [Phase] 
~  Dollars 


Fiscal  Reset= 

IF  THEN  ELSE(Fiscal  Counter=12?Fiscal  Counter/TIME  STEP,0) 
~  Dimensionless 


Net  Approved[Phase]= 

SUM(Approved[Phase.  Discipline!]) 
Tasks 


Change  to  Budget[Phase]= 

Current  Phase[Phase]*Funding  Gap[Phase]/Timc  to  Change  Budget 
Dollars/Month 


Net  Completed[Phase]= 

SUM(Completed[Phase.Disciphne!]) 
~  Tasks 


Contractors  Phase[Phase]= 

SUM(ContractorExperienced[Phase.Discipline!])+SUM(ContractorNew[Phase,Discipline!]\ 

) 
~  Manpower 

I 
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Desired  Manpower  Phase  [Phase] = 

SUM(Adjusted  Desired  Manpower[Phase.  Discipline!]) 
~  Manpower 


NAVSEA  Phase[Phase]= 

SUM(NAVSEAExpenenced[Phase,Disciphne!])+SUM(NAVSEANew[Phase,Disciphne!]) 
~  Manpower 

Contractor  New  Desired  Release[Phase.Discipline]= 

IF  THEN  ELSE(-Manpower  Shortage[Phase.Discipline]>0,MAX(0,  ABS(Manpower  Shortage  [Phase\ 

,Discipline])*(l -NAVSEA  Participation  Adjusted  Percentage[Phase,Discipline])*(ABS(l\ 

-Effect  of  Available  Budget  on  Contractors[Phase]))),0) 
~  Manpower 

~  When  personnel  supluses  exist,  new  contractors  are  released  based  as  the  \ 

fraction  of  manpower  shortage  desired  as  contractors 


Review  Error  Rate[Phase.Discipline]= 

Review  Error  Rate  f[Phase.Discipline] 

~  Tasks/Month 

The  rate  of  external  Q/A  and  defective  discovery  is  the  probability  of  a  \ 
defect  times  the  probability  of  discovering  the  defect  times  the  minimum  \ 
of  tasks  available  for  inspection  (reviewed  tasks  over  the  time  to  detect)  \ 
and  the  inspector  constraint  (QA  constraint) 


Fiscal  Counter  Increase= 
1 

Dimensionless 


TimeToGetFatigued  =  1 
Month 


Total  Tasks[Phase]= 

Net  Approved[Phase]+Net  Completed[Phase]+Net  Review  [Phase] +Net  TB  Coordj  Phase] +Net  TBD\ 

[Pliase]+Net  WlP[Phase] 
~  Tasks 


Net  TB  Coord[Phase]= 

SUM(TBCoord[Phase,Discipline!]) 
Tasks 


Net  TBD[Phase]= 

SUM(TBD[Phase.Discipline!]) 
~  Tasks 


Net  WTP[Phase]= 
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SUM(WIP[Phase.Discipline !  ] ) 
~  Tasks 


Fatigue[Phase.Discipline]=  INTEG  ( 

GettingFatigued[Phase.Discipline] 

1) 
~  fraction 


Contractor  New  Assignments[Phase,Discipline]= 

MAX(O.Effect  of  Available  Budget  on  Contractors[Phase]*Manpower  Shortage[Phase,Disciphne\ 
]*(1-NAVSEA  Participation  Adjusted  Percentage  [Phase.  Discipline])) 

~  Manpower 

Assignments  will  occur  as  the  Manpower  Shortage  times  the  fraction  of  \ 
non-NAVSEA  personnel  required  times  a  factor  for  budget  available 


Effect  of  Available  Budget  on  Contractors! Phase] = 

Effect  of  Available  Budget  on  Contractors  f(Available  to  Desired  Budget  [Phase]) 
~  Manpower 


Fiscal  Counter=  INTEG  ( 

Fiscal  Counter  Increase-Fiscal  Reset. 

0) 
~  Month 


Perceived  Funding  Requirements[Phase]= 

Total  Contractors  Assigned[Phase]*  Contactor  Cost*Current  Phase[Phase]*ABS(Max  Indicated 
Completion  Date 

[Phase]-Time) 

~  Dollars 


Program  Budget  Rate[Phase]= 

Annual  Funding[Phase]*Current  Phase[Phase]/Funding  Period 
~  Dollars/Month 


Effect  of  Schedule  Gap  on  Desired  Manpower  f( 

[(-40,0)-(40,10)].(-24.0.25).(-12.0.5).(0.1).(3.1.25).(12,2),(24.4)) 
~  Dimensionless 


Manpower  Shortage[Pliase.Discipline]= 

Adjusted  Desired  Manpower[Phase.Disciplinc] -Personnel  Assigned[Phase.Discipline] 
~  Manpower 

I 

Contract  Establishment  Rate[Phase.Discipline]= 

Percentage  of  RFP  Contracts[Phase]*Contractor  Pool[Phase.Disciplme]/Contracting  with  RFP  Rate\ 

[Phase.Disciphne]+(l -Percentage  of  RFP  Contracts  [Phase])*  Contractor  Pool  [Phase,  Disciphne\ 
]/Contracting  with  Existmg  NAVSEA  Contracts[Phasc.Discipline] 
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Manpower/Month 


minimumCompletionDurauon= 
1 
~  Month 


NAVSEA  New  Assignments[Phase.Discipline]= 

IF  THEN  ELSE  (Manpower  Shortage[Phase.Discipline]>0,Manpower  Shortage[Phase.Discipline\ 

]*NAVSEA  Participation  Adjusted  Percentage  phase.  Discipline],0) 
~  Manpower 

~  For  existing  manpower  shortage,  the  assigment  of  NAVSEA  Personnel  is  the  \ 

desired  fraction  of  NAVSEA  personnel  times  the  required  personnel 


Schedule  Gap[Phase.Discipline]= 

Indicated  Completion  DatefPhase. Discipline] -Desired  SchedulefPhase.Discipline] 
~  Month 


NAVSEA  Exp  Desired  Release[Phase.Discipline]= 

IF  THEN  ELSE(NAVSEA  New  Desired  Release[Phase,Disciplinel<O.O.MAX(O.NAVSEA  New  Desired 
Release\ 

[Phase,Discipline]-NAVSEANew[Phase.Discipline])) 
~  Manpower 

~  When  NAVSEA  personnel  are  being  released  (NAVSEA  New  Desired  Release  is  \ 

positive)  expenenced  personnel  are  released  only  after  all  new  personnel  \ 
have  been  released 


DesiredAccomplishingRate[Phase.Discipline]= 

Perceived  TBD[Phase.Disciplinel  /  Remaining  Design  Phase  Duration[Phase.Discipline] 
~  Tasks/Month 


Remaining  Design  Phase  Duration[Phase.Disciplme]= 

MAX(minimumCompletionDuration.  Desired  SchedulefPhase.Disciphne]  -  Time) 
~  Month 


NAVSEA  New  Desired  Releasc[Phase.Discipline]= 

IF  THEN  ELSE(Manpower  Shortage[Pnase.Discipline]>0,0. NAVSEA  Participation  Adjusted  Percentage\ 

[Phase.Disciphne]*ABS(Manpower  Shortage[Phase.Discipline])) 
~  Manpower 

Percentage  of  RFP  Contracts  [Phase] = 
0.01,0.1,0.2,0.8,0.9 

~  Dimensionless 

~  The  average  fraction  of  total  contracts  which  are  RFP's  vice  existing  \ 

NAVSEA  contracts 


Effect  of  Schedule  Gap  on  Desired  ManpowerfPhase.Discipline] 
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Effect  of  Schedule  Gap  on  Desired  Manpower  f( Schedule  Gap|Phase.Discipline]) 
~  Dimensionless 


Contractor  Exp  Desired  Release[Phase,Discipline]= 

IF  THEN  ELSE(Contractor  New  Desired  Release[Phase.Discipline]<O.O.MAX(O.Contractor  New  Desired 
Release\ 

[Phase.Disciphne] -Contractor  NewfPhase.Discipline])) 
~  Manpower 

I 

Contractor  Release  Pen  d= 
1 

~  Month 

~  Time  required  to  release  personnel  from  the  current  project  is 

I 

Contractors  Available[Phase.Discipline]=  INTEG  ( 

Contractor  Experience  Release  Rate[Phase,Discipline]+Contractor  New  Released[Phase,Disciphne\ 
]-Contracted  Assign  Rate[Phase.Discipline]+Contract  Establishment  Rate[Phase.Discipline\ 

]- 

0) 

~  Manpower 

I 

NAVSEA  Experience  Gain  Period[Phase]= 
6 

~  Month 

~  Months  required  for  mdividuals  to  acquire  full  working  knowledge  of  the  \ 

current  project 
I 

NAVSEA  Release  Period= 
1 

~  Montli 

~  Time  required  to  release  persoimel  from  the  current  project  is 

Contractor  New[Phase.Discipline]=  INTEG  ( 

Contracted  Assign  Rate[Phase.Discipline]-Contractor  Experience  Gain  Rate[Phase.Discipline\ 
] -Contractor  New  Released[Phase.Discipline], 
0) 
~  Manpower 

I 

EffectOfFatigueOnProductivityf  Phase. Discipline] = 

EffectOfFatigueOnProducthirv  f(  Fatigue  [Phase.Disciphne]) 
-  dmnl 


Contracting  with  Existing  NAVSEA  Contracts[Phase.Discipline]= 
3 
~  Montli 

Months  required  to  negotiate  design  work  through  existing  NAVSEA  Contracts 
I 
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Contracting  with  RFP  Rate[Phasc,Discipline]= 
18 

~  Month 

~  Months  required  to  negotiate  design  work  through  new  (RFP-request  for  \ 

proposals)  contracts 
I 

PDY  Contractor  Experienced  Factor= 
1.1 
~  Dimensionless 

Contractor  Experienced  Personnel  have  an  increased  productivity  of  20%  \ 

greater  than  that  of  an  average  designer 
I 

Contractor  Baseline  Personnel[Phase.Discipline]= 
50 
~  Manpower 

NAVSEA  Personnel  available  for  assignment  to  the  project  by  discipline  and  \ 

phase 
I 

Contractor  Experience  Gain  Period[Phase]= 
6 

~  Month 

~  Months  required  for  individuals  to  acquire  full  working  know  ledge  of  the  \ 

current  project 
I 

Contractor  Experience  Gain  RatelPhase. Disciplined 

Contractor  New[Phase.Disciplinc]/Contractor  Experience  Gain  Period[Phase] 
~  Manpower/Month 

The  rate  of  transfer  of  personnel  from  new  to  project  to  experienced  with  \ 
the  project  is  the  number  of  personnel  over  the  average  time  to  acquire  \ 
experience 


Contractor  Expenenced[Phase, Discipline^  INTEG  ( 

Contractor  Experience  Gain  Rate[Phase.Discipline]-Contractor  Experience  Release  Rate\ 

[Phase.  Discipline], 

0) 
~  Manpower 

The  accumulation  of  NAVSEA  personnel  with  direct  experience  with  the  \ 

current  design  Project  is  0  plus  the  rate  of  experience  gain  less  the  \ 

release  rate  of  experienced  personnel  from  the  project 


Indicated  Completion  Date[Phase.Discipline]= 

Current  Phase  [Phase  ]*(Time+IF  THEN  ELSE(Estimated  Comp  Rate[Phase.Discipline]<=0,60.\ 

Perceived  TBD[Phase.Discipline]/Estimatcd  Comp  Rate 
[Phase.Disciplme])) 
~  Month 

~  The  estimated  months  to  completion  (per  discplme  per  phase)  is  0  if  the  \ 

phase  is  inactive  (either  passed  or  not  yet  started)  or  is  the  TBD  divided  \ 

by  the  current  rate  of  completion  (personnel  by  personnel  \ 

175 


productivity)... note  at  phase  start,  no  personnel  are  assigned  so  an  \ 
artificial  estimate  of  60  months  is  set. 


Contractor  Pool[Phase,Discipline]=  INTEG  ( 

-Contract  Establishment  RatefPhase.Discipline], 

Contractor  Baseline  Personnel  [Phase.Discipline]) 
~  Manpower 

~  The  pool  of  available  contractors  not  available  because  contracts  are  not  \ 

yet  in  place  to  allow  their  use 


PDY  NAVSEA  Experience  Factor= 
1.1 
~  Dimensionless 

NAVSEA  Experienced  Personnel  have  an  increased  productivity  of  20%  greater  \ 
than  that  of  an  average  designer 


EffectOfFatigueOnProductivitv  f( 

[(0.0)-(4,4)].(0,l),(1.2.1.01).(1.5,1.5).(2,2).(3,2.1)) 
~  dmnl 


EffectOfScheduleGapOnProductivit>f( 

[(-10,0)-(10,1.75)],(-10,0.75).(0.0.9),(0.757732.0.904605).(L1),(1.5.1.1),(2.50755.\ 

1.25877),(3. 83686,1. 5274 1),(5, 1 .684),(  10, 1 .  75)) 
~  dmnl 


PDY  NAVSEA  New  Factor= 
0.85 
~  Dimensionless 

NAVSEA  Personnel  new  to  the  project  have  an  increased  productivity  of  20%  \ 
less  than  that  of  an  average  designer 


Estimated  Comp  Rate|Phase. Discipline^ 

Avg  Design  Rate[Phase,Discipline]*Personnel  Assigned[Phase.Discipline] 
~  Tasks/Month 


PDY  Contractor  New  Factor= 
0.85 

~  Dimensionless 

~  Contractor  Personnel  new  to  the  project  have  a  productivity  of  20%  less  \ 

than  that  of  an  average  designer 


Spending  Rate[Phase]= 

Total  Contractors  Assigned[Phase]*Contactor  Cost 
~  Dollars/Month 


Desired  Tasks  to  Assign[Phase.Discipline]= 
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Personnel  Assigned[Phase,Discipline]*Net  Productivity  Rate[Phase.Discipline]*Design  Phase  Duration\ 

[Phase] 
~  Tasks 

~  The  desired  number  of  tasks  to  be  assigned  (by  discipline)  at  a  given  time  \ 

in  a  phase  is  the  number  of  personnel  available  to  work  times  the  \ 

effective  productivity  of  those  personnel  times  months  number  of  months  \ 

into  the  project 


Design  Phase  Duration  [Phase  ]=  INTEG  ( 
Design  Phase  Time  StepfPhase], 

0) 
~  Month 

~  From  the  start  of  a  design  phase,  how  many  months  have  passed . . 

I 

Design  Phase  Time  Measure= 
1 

~  Month 

~  The  basic  measurement  of  design  duration  is  1  month  of  time 


Design  Phase  Time  StepfPhase] = 

Current  Phase[Phase]*Design  Phase  Time  Measure/Design  Phase  Time  Measure 

~  Month/Month 

~  The  rate  of  increase  of  the  design  duration  for  a  current  phase  (Current  \ 

Phase  equals  1)  is  the  current  model  time  step  over  the  basic  measurement  \ 

of  time  ( 1  month) 
I 

Assign  Rate  [Phase.  Discipline] = 

MIN(TBD[Phase.Discipline]/Assign  PeriodDesired  Tasks  to  Assign[Phase.Disciphne]/Assign  Period\ 

) 
~  Tasks/Month 

The  assignment  rate  is  the  minimum  of  the  assignable  task  constraint  (TBD  \ 
over  assignment  period)  and  the  desired  task  assignment  constraint  \ 
(desired  tasks  for  assignment  over  the  assignment  period) 

Release  Rate[Phase. Disciplined 

Baseline  Tasking[Phase. Discipline]* Current  Phase[Phase]/TIME  STEP 

~  Tasks/Month 

~  At  the  commencement  of  a  design  phase,  all  baseline  tasks  are  released  to  \ 

TBD  for  assignmenet  to  designers,  the  release  is  dependent  on  the  phase  \ 
becoming  active... time  step  is  used  to  provide  the  release  in  a  single  \ 
pulse. 


Time  to  Detect  Errors[Phase]= 
1 

~  Month 

~  The  minimum  time  (by  phase)  required  to  detect  an  error  in  a  task 


Current  to  Future  Phase[Conccpt]= 
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1H 

Current  to  Future  Phase  [Preliminary  ]= 

Effect  of  Percent  Phase  Complete  on  Current  to  Future  ffPercent  Phase  Complete[Concept\ 
]/Percent  Phase  Complete  Desired[Concept])  —| 
Current  to  Future  Phase[Contract]= 

Effect  of  Percent  Phase  Complete  on  Current  to  Future  f(Percent  Phase  Complete[Preliminary\ 
]/Percent  Phase  Complete  Desired[Preliminary])  ~~| 
Current  to  Future  Phase  [Lead  Ship]= 

Effect  of  Percent  Phase  Complete  on  Current  to  Future  ffPercent  Phase  Complete[Contract\ 
]/Percent  Phase  Complete  Desired[Contract])  ~~| 
Current  to  Future  Phase  [Manufacturing^ 

Effect  of  Percent  Phase  Complete  on  Current  to  Future  ffPercent  Phase  CompletefLead  Ship\ 

]/Percent  Phase  Complete  Desired[Lead  SliipJ ) 
~  Dimensionless 

~  A  design  phase  can  start  (equals  1)  when  the  previous  design  phase  ratio  \ 

of  completed/approved  tasks  to  desired  approved  tasks  is  greater  than  1  \ 
(bv  the  Effect  of  Percent  Phase  Complete  function. ) 
I 

WIP[Phase,Discipline]=  INTEG  ( 

Assign  Rate[Phase,Discipline]+Coord  Rate[Phase.Discipline]-Comp  Rate[Phase.Discipline\ 

]• 

0) 
~  Tasks 

~  Work  is  progress  is  the  number  of  tasks  released  from  initial  work  (assign  \ 

rate)  plus  the  rework  tasks  returning  from  coordination  (coord  rate)  less  \ 

the  tasks  completed  bv  designers  (comp  rate) 
I 

Net  Comp  Rate= 

SUM(Comp  Rate[Concept.Discipline!])+SUM(Comp  Rate[Prelirmnary.Disciplme!])+SUM(Comp  Rate\ 

[Contract.Disciplme ! ] )+SUM( Comp  Rate 
[Lead  Shin.Discipline!])+SUM(Comp  Rate[Manufacturing,Discipline!]) 
~  Tasks/Month 


Appro^  al  Phase[Phase]= 

Approval  Phase  Effect  f( Approval  Ratio  Actual [PhaseJ/Approval  Ratio  DesiredfPhase]) 
~  Dimensionless 

Tlie  approval  phase  is  active  (1)  for  actual  to  desired  ratios  greater  than  \ 
1  and  inactive  (0)  for  ratios  less  than  1 


Approval  Phase  Effect  f( 

[(0,0H2,1)].(0,0).(0.75,0),(0.999.0).(1.1).(2.1)) 
~  Dimensionless 

The  approval  Phase  Effect  Function  compares  the  ratio  of  Approval  Ratio  \ 
Actual  to  Desired  for  net  ratios  greater  than  1.  the  approval  phase  is  \ 
active  ( 1 )  for  ratio  less  than  1  the  approval  phase  is  not  active  (0) 


Approval  Ratio  Actual  [Phase] = 

(SUM(Approved[Phase.Discipline!])+SUM(Review[Phase.Disciplme!]))/SUM(Initial  Tasks [\ 

Phase.Discipline!]) 
~  Dimensionless 
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The  Ratio  of  total  tasks  available  for  or  already  approved  to  the  total  \ 
inrial  tasks  is  the  total  of  tasks  released  at  review  and  those  residing  \ 
as  Approved  divided  by  the  initial  tasks  ...by  phase. 


Completed[Phase.Discipline]=  INTEG  ( 

+Comp  Rate  [Phase.  Discipline] -Review  Rate[Phase.Discipline]-Internal  Error  Rate[Phase\ 

.Discipline]  -Design  Spiral  Rate  [Phase. 
Discipline], 

0) 
~  Tasks 

~  Completed  tasks  are  increased  by  the  completion  rate  (Comp  Rate)  and  \ 

decreased  by  release  of  tasks  for  NAVSEA  review  (Review  Rate),  rework  of  \ 

tasks  due  to  concurrent  feedback  (Design  Feedback  Rate)  and  rework  due  to  \ 

discovered  errors  (Defective  Rate) 


Approve  Rate  [  Phase .  Di  scipl  ine] = 

Approval  Phase  [Phase]  *  ( Review  [Phase.  Discipline]/Approval  Period[Phase] ) 

~  Tasks/Month 

The  rate  of  approval  of  tasks  by  DoN/DoD  is  the  indicator  that  tasks  \ 
levels  will  support  approval  process  (Approval  Phase  equals  1)  times  the  \ 
approval  rate  (reviewable  tasks  over  the  time  required  to  review  a  task) 


Effect  of  Percent  Phase  Complete  on  Current  to  Future  f( 
[(0,0)-(2.1)],(0,0),(0.999,0).(U),(2.1)) 
~  Dimensionless 


Effect  of  Percent  Phase  Complete  on  Current  to  Past  f( 
[(0.0)-(2,l)],(0,l),(0.999,l),(l,0),(2,0)) 
~  Dimensionless 


Comp  Rate[Phase. Discipline^ 

Comp  Rate  f[Phase,Discipline] 

~  Tasks/Month 

The  rate  of  completion  of  tasks  is  the  average  completion  rate  for  tasks  \ 
(...see  resource  sector  for  first  order  control  of  comp  rate) 


TBD[Phase.Disciplme]=  INTEG  ( 

-Assign  Rate[Phase.Disciplme]+Release  Rate[Phase.Disciphne]+Rescope  Rate[Phase.Discipline\ 

]• 

0) 
~  Tasks 

~  TBD  is  the  quantity  of  tasks  available  for  assignment  increased  by  release  \ 

(at  phase  start)  and  by  rescoping  of  the  project  (design  change  \ 

introduction)  by  authorities.  TBD  is  decreased  by  the  assignment  rate  \ 

(assigning  tasks  to  designers) 


Current  to  Past  Phase [  Concept  ]= 

Effect  of  Percent  Phase  Complete  on  Current  to  Past  f(Current  to  Future  Phase[Preliminary\ 
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Current  to  Past  Phase[Preliminar>]= 

Effect  of  Percent  Phase  Complete  on  Current  to  Past  f(  Current  to  Future  Phase  [Contract 

])H 
Current  to  Past  PhasefContract]= 

Effect  of  Percent  Phase  Complete  on  Current  to  Past  f(Current  to  Future  PhasefLead  Ship\ 

])H 
Current  to  Past  Phase[Lead  Ship]= 

1—| 
Current  to  Past  Phase[Manufacturing]= 
1 

~  Dimensionless 

~  A  phase  is  finished  (equals  0)  when  tlie  next  design  phase  has  achieved  an  \ 

indicator  value  (Current  to  Future  Phase)  for  phase  initiation  (equals  \ 
l)...acliieved  through  the  table  function  Effect  of  Percent  complete. 


TBCoord[Phase.Discipline]=  INTEG  ( 

+Design  Spiral  Rate[Phase.DisciplineJ-Coord  Rate[Phase.Discipline]+Intemal  Error  Rate\ 

[Phase,Discipline]+Review  Error  Rate[Phase,Discipline], 

0) 
~  Tasks 

~  The  tasks  requiring  coordhiation  prior  to  rework  are  increased  by  the  \ 

tasks  requiring  rework  (design  feedback  rate,  defective  rate  and  reject  \ 

rate)  less  those  tasks  completing  coordination  and  returning  to  the  work  \ 

cycle  (coord  rate) 


NAVSEA  Baseline  Personnel[Phase. Discipline^ 
7 
~  Manpower 

NAVSEA  Personnel  available  for  assignment  to  the  project  by  discipline  and  \ 
phase 


Desired  Schedule[Phase.Discipline]=  INTEG  ( 
Schedule  Shift[Phase.Discipline], 

Initial  Schedule  Projection[Phase]) 
~  Month 

The  Desired  Schedule  is  the  initial  schedule  (months  to  phase  completion  \ 
from  project  start)  estimate  for  each  phase  increased  (or  decreased)  by  \ 
the  rate  of  schedule  shift 


Perceived  TBD[Phase.Discipline]= 

Current  Phase[Phase]*MAX(0. Initial  Tasks[Phasc.Discipline]*Percent  Phase  Complete  Desired\ 

[Phase] -Perceived  Completed[Phase. Discipline]) 
~  Tasks 

~  The  perceived  TBD  (for  an  active  phase  as  determined  by  the  boolean  \ 

Current  Phase)  is  the  maximum  of  0  (floor  value)  and  the  tasks  required  to  \ 

close  the  phase  (initial  tasks  times  transition  ratio)  minus  the  perceived  \ 

completed  tasks. 


Net  Personnel  Assigned^ 
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SUM(Net  Personnel  Assigned  Phase  [Phase!]) 
~  Manpower 

~  Net  Personnel  Assigned  (by  project)  is  the  sum  of  personnel  assigned  by  \ 

phase 


Annual  Funding[Phase]=  INTEG  ( 
Change  to  Budget  [Phase], 

Planned  Annual  Funding[Phase]) 
~  Dollars 


Net  Perceived  TBD[Phase]= 

SUM(PerceivedTBD[Phase.Discipline!]) 

~  Tasks 

~  Net  Perceived  TBD  (by  phase)  is  the  sum  of  TBD  by  design  discipline 


Effect  of  Available  Budget  on  NAVSEA  Percent  f( 

[(0,0)-(l,l)].(0.1),(0.05,l),(0.1,0.9),(0.2,0.75),(l,0.75)) 
~  Dimensionless 


Available  Budget[Phase]=  INTEG  ( 

-Spending  Rate[Phase]+Program  Budget  RatefPhase]. 

1) 
~  Dollars 


Coord  Rate  fTPhase.  Disciplined 

TBCoord[Phase.Discipline]/Average  Coord  Period[Phase.Discipline] 
~  Tasks/Month 

Average  Coordination  Rate  is  the  Tasks  available  for  coordination  over  the  \ 

time  required  to  coordinate  a  task 


Coord  Rate[Phase.Discipline]= 

Coord  Rate  f[Phase,Discipline] 

~  Tasks/Month 

The  rate  of  coordination  of  tasks  is  the  average  coordination  rate  for  \ 
tasks  (...see  resource  sector  for  first  order  control  of  coord  rate) 


Net  Coord  Rate[Phase]= 

SUM(Coord  Rate  f[Phase.Disciplme!]) 
~  Tasks/Month 


Time  to  Change  Budget= 
36 

Month 


Contactor  Cost= 
6597 
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~  Dollars/(Month*Manpower) 

The  average  monthly  cost  per  contractor,  including  overhead  costs,  in  FY96  \ 

dollars 
I 

Spent  Budget[Phase]=  INTEG  ( 
Spending  Rate  [Phase]. 

0) 
~  Dollars 


NAVSEA  Assign  Period= 
1 
~  Month 


Time  to  Shift  Schedule= 
24 
~  Month 


Perceived  Completed[Phase.Discipline]= 

Review  [Phase.Discipline]+Completed[Phase.Discipline]+Approved[Phase.Discipline] 
~  Tasks 

~  Perceived  completed  is  the  number  of  tasks  in  review  plus  those  awaiting  \ 

review  (completed)  plus  those  approved 


Contractor  Assign  Period[Phase]= 
1 
~  Month 


Net  Perceived  Completed[Phase]= 

SUM(Perceived  Completed[Phase.Discipline!]) 
~  Tasks 

Net  perceiev  ed  completed  tasks  (by  phase)  are  the  sum  of  all  perceived  \ 
completed  tasks  by  design  discipline 


Net  Personnel  Assigned  PhasefPhase]= 

SUM(Personnel  AssignedfPhase.Disciphne!]) 
~  Manpower 

~  Net  Current  Personnel  Assigned  (by  phase)  is  the  sum  of  personnel  assigned  \ 

by  design  discipline 


Step  Down  Time= 
0 
~  Month 


Pink  Noise  -  INTEG(Change  in  Pink  Noise.O) 
~  Dimensionless 

Pink  Noise  is  first-order  autocorrelated  noise.  Pink  noise  provides  a  realistic  \ 
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Input= 


noise  input  to 

models  in  which  the  next  random  shock  depends  in  part  on  the  previous  \ 
shocks.  The  user 

can  specify  the  correlation  time.  The  mean  is  0  and  the  standard  deviation  \ 
is  specified 

by  the  user. 


MAX(Pmk  Noise,MIN(STEP(Step  Height. Step  Up  Time)+ 
(Pulse  Quantity/TIME  STEP)*PULSE(Pulse  Time.TIME  STEP)+ 
RAMP(Ramp  Slope.Ramp  Start  Time.Ramp  End  Time)+ 
Sine  Amplitude*SIN(2*3. 14159*Time/Sine  Period)+ 

STEP(l,Noise  Start  Time)*Pink  Noise,  l-STEP(Step  Height.Step  Down  Time))) 
~  Dimensionless 

~  Input  is  a  dimensionless  variable  wliich  provides  a  variety  of  test  input  patterns.  \ 

including  a  step, 

pulse,  sine  wave,  and  random  noise. 


Change  in  Pink  Noise  =  (White  Noise  -  Pink  Noise)/Noise  Correlation  Time 
1/Month 
~  Change  in  the  pink  noise  value;  Pink  noise  is  a  first  order  exponential  smoothing  \ 

delay  of  the  white 
noise  input. 


Sine  Amplitude^ 

1 


Sine  Period= 

25 


Dimensionless 

Amplitude  of  sine  wave  in  customer  orders  (fraction  of  mean). 


Month 

Period  of  sine  wave  in  customer  demand.  Set  initially  to  50  weeks  ( 1  \ 

year). 


Step  Height= 
1 

~  Dimensionless 

-  Height  of  step  input  to  customer  orders,  as  fraction  of  initial  value. 


Pulse  Quantitv= 
1 

~  Month 

~  The  quantity  to  be  injected  to  customer  orders,  as  a  fraction  of  the  base  value  of  \ 

Input 

For  example,  to  pulse  in  a  quantity  equal  to  50%  of  the  current  value  of  \ 
input,  set  to 
.50. 
I 
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Pulse  Time= 
62 
~  Month 

Time  at  which  the  pulse  in  Input  occurs. 


White  Noise  =  Noise  Standard  Deviation*((24*Noise  Correlation  Tmie/TIME  STEP)A0. 5*  (RANDOM  0  1\ 
0-0.5 

)) 

~  Dimensionless 

~  White  noise  input  to  the  pink  noise  process. 


Noise  Correlation  Time  =  4 
~  Month 

~  The  correlation  time  constant  for  Pink  Noise. 


Ramp  Slope=0 

1/Month 
~  Slope  of  the  ramp  input,  as  a  fraction  of  the  base  value  (per  week). 

I 

Ramp  Start  Time= 
0 

~  Month 

~  Start  time  for  the  ramp  input. 

I 

Ramp  End  Time=le+009 
~  Month 

~  End  time  for  the  ramp  input. 


Noise  Standard  Deviation= 
0.5 
~  Dimensionless 

The  standard  deviation  of  the  pink  noise  process. 
I 

Noise  Start  Time= 
0 
~  Month 

Start  time  for  the  random  input. 


Step  Up  Time= 
0 

~  Month 

~  Time  for  the  step  input. 


Approved[Phase.Discipline]=  INTEG  ( 

Approve  Rate[Phase.Discipline|. 
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Tasks 

The  total  tasks  (by  discipline)  approved  by  DoN/DoD  and  considered  removed  \ 

from  the  phase 


Total  Approved  Tasks  [Phase] = 

SUM(Approved[Phase,Discipline!]) 

~  Tasks 

~  The  total  approved  tasks  for  all  disciplines  in  a  single  design  phase 


Approval  Period[Phase]= 
1,1,1.0.125,0.125 
~  Month 

~  The  current  time  required  to  review  a  task  by  DoN/DoD  is  considered  3  \ 

months 


Approval  Ratio  Desired[Phase]; 
0.8,0.9,0.95,0.5,0.5 
~  Tasks/Tasks 


ReviewfPhase, Disciplined  INTEG  ( 

Review  RatefPhase.Discipline] -Approve  Rate[Phase.Disciphne]-Review  Error  Rate [Phase\ 

.Discipline], 

0) 
~  Tasks 

~  Tlie  tasks  reviewed  by  NAVSEA  are  increased  by  the  review  rate  and  \ 

decreased  by  those  tasks  rejected  to  rework  (errors  discovered)  and  those  \ 

design  tasks  provided  to  DoN/DoD  for  final  approval 


Baseline  Tasking[Phase.Discipline]=  INTEG  ( 

-Release  RatefPhase.Discipline]. 

Initial  Tasks[Phase,Discipline]) 

~  Tasks 

~  The  Initial  Stock  of  design  tasks  for  the  23  design  disciplines  and  5  \ 

phases,  the  stock  is  drained  to  0  at  the  commencement  of  each  phase  (the  \ 
phase  becomes  active.)  This  stock  initiates  the  model  for  a  phase 


Percent  Phase  Complete  Desircd[Phase]= 
0.8.  0.9.  0.95.  0.75,  0.5 
~  Tasks/Tasks 


Phase: 

Concept.  Preliminary.  Contract.  Lead  Ship.  Manufacturing 
~  Tasks/Tasks 


Assign  Period= 

1 
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Month 

The  average  time  required  to  assign  a  task  is  1  month 


Discipline: 

Al.  A2.  A3,  Bl.  B2,  B3,  B4,  B5,  CI.  C2,  C3.  C4,  C5,  C6,  C7.  Dl.  D2,  D3,  D4,  D5,  El.  \ 

E2,  Fl 


I 


Feedback: 


Al.  A2.  A3,  Bl.  B2.  B3,  B4,  B5.  CI.  C2.  C3.  C4.  C5.  C6.  C7.  Dl.  D2.  D3.  D4.  D5.  El.  \ 
E2.F1 

I 

Initial  Tasks[Concept.Discipline]= 

8.  8.  12,  2.  1,  1.  4.  2.  4,  6,  2,  1.  2.  7.  5.  3.  2,  2.  2,  1,  3.  2.  3  ~~| 
Initial  Tasks[Preliminarv,Discipline]= 

10,8.  13,2.3,2,5,4,4,  19,2,  1.  11,  15,  16.8,7,7,  12.7.9,  5,  4 — ] 
Initial  Tasks[Contract,Discipline]= 

13.  8.  13.  2,  4,  2,  5,  4,  4,  20,  2.  2.  1 1.  18,  16,  9.  8,  8,  14,  7.  10.  5,  6  ~~| 
Initial  Tasks[Lead  Ship.Discipline]= 

41.  25.  39.  6.  14.  9,  15.  12.  12.  60.  6.  6.  33.  54.  54.  35.  24.  24.  42.  21.  30.  15.  \ 
18  — j 
Initial  Tasks[Manufacturing,Discipline]= 

14,  9,  13.  2,  5.  3,  5.  4.  4,  20,  2.  2,  1 1,  18,  20.  12.  8.  8.  14.  7.  10.  5.  6 
~  Tasks 

~  The  baseline  number  of  total  deliverable  tasks  for  each  of  the  23  design  \ 

disciplines  for  each  of  the  five  design  phases... values  determined  from  \ 
DDG-5 1  Design  Histories  and  evaluations  from  the  Laverghetta  Design  Thesis 


Review  Period[Phase]= 

0.325.0.325.0.325.0.1,0.1 
~  Month 

Minimum  time  reqiured  to  review  a  single  task 


Design  Spiral  Matnx[Al,Discipline]= 

0,  0,  0,  0,  0,  0,  0,  0,  0.  0.  0.  0.  0.  0.  0,  0.  0.  0.  0,  0,  0.  0,  0 
Design  Spiral  Matrix[A2.Discipline]= 

1.0.  1.  1.  1.  1,  1,  1,  1,  1,  1,  1.  1.  1.  1,  1.  1.  1,  1.  1,  1,  1.  1 
Design  Spiral  Matrix[A3.Discipline]= 

1.  1.  0.  1.  1,  1,  0.  1,  1.  0,  0,  0.  1.  1.  0.  1.  1.  1.  1.  1.  1.  1.  1 
Design  Spiral  Matrix[Bl. Disciplined 

1.1,0,  0,  0,  1,  1.  0,  0.  0.  0,  0.  0,  0.  0.  0.  0,  0,  0,  0.  0.  0,  0 
Design  Spiral  Matrix[B2, Discipline^ 

1.1.0,  1,  0,  1.  0,  0.  0,  0,  0,  0.  0,  0.  0.  0,  0,  0.  0,  0,  0,  0.  0 
Design  Spiral  Matrix[B3. Disciplined 

1,  1.  0,  0.  1,  0,  0,  0.  0,  0.  0,  0,  0,  0.  0.  0.  0.  0.  0,  0,  0,  0,  1 
Design  Spiral  Matrix[B4.Disciplme]= 

1.  1.  0.  0,  0,  0,  0,  1,  1,  1,  0,  0,  1,  1,  1,  1.  1.  1,  1,  1.  1.  1,  0 
Design  Spiral  Matrix[B5,Discipline]= 

1,  1.  0,  1,  1.  0.  1.  0,  0,  0.  0.  0.  0,  0,  I,  1.  0.  1,  1,  0.  0.  0.  1 
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Design  Spiral  Matnx[Cl,Discipline]= 

1.  1.  0,  0.  1,  1,  0.  0.  0,  1.  1.  1,  1.  1.  1,  1,  1.  1.  1.  0.  0.  0.  1  - 
Design  Spiral  Matrix[C2.Discipline]:= 

1.  1,  0,  0.  1,  1,  1,  0.  0.  0,  0.  1.  1.  1,  1.  1.  1.  1.  1,  1,  1,  1.  1  - 
Design  Spiral  Matrix[C3. Discipline^ 

1,  1,  0.  0,  0,  0.  1.  0.  0.  0.  0.  1.  0.  0.  0.  1.  1.  0.  0.  0,  0.  0,  0  - 
Design  Spiral  Matnx[C4,Discipline]= 

1,  1.  0,  0,  0.  0.  1,  0,  0,  1.  0.  0.  0.  1.  0.  0,  0.  0.  0.  1.  1,  0,  0  - 
Design  Spiral  Matrix[C5, Discipline^ 

1,  1,  0,  1,  1,  1.  1,  0,  0,  1.  1.  1.  0.  1,  1,  1,  1.  1.  1.  0.  0.  0.  1  - 
Design  Spiral  Matrix[C6,Discipline]= 

1.  1.  0.  1,  1.  1,  1.  0,  0.  1,  0,  0,  0,  0.  1.  0.  0.  0.  0.  0.  0.  0.  1  - 
Design  Spiral  Matrix[C7,Discipline]= 

1,  1,  0.  1.  1,  1.  1.  1.  0.  1.  0,  0.  0,  1,  0,  1.  1,  1.  1.  1.  1.  1.  1  - 
Design  Spiral  Matrix[Dl.Discipline]= 

1.  1,  0,  1,  1,  1.  1.  1,  0,  1,  0,  0,  0,  1.  1.  0.  1,  1.  1.  1.  0.  0,  1  - 
Design  Spiral  Matnx[D2,Discipline]= 

1.  1.  0.  1.  1.  1.  1.  1,  0.  1.  1,  0,  1.  1.  1.  1.  0.  1.  1.  0.  0.  0.  1  - 
Design  Spiral  Matrix[D3, Discipline^ 

1,  1.  0,  1.  1.  1,  1,  1.  0.  1.  0.  0,  0.  1.  1.  1,  1,  0,  1.  1.  1.1.1- 
Design  Spiral  Matrix[D4,Discipline]= 

1,  1,  0.  1,  1.  1.  1.  1,  0,  1.  0.  1.  1.  1.  1.  1,  1.  1.  0.  1,  1.1.1- 
Design  Spiral  Matrix[D5.Discipline]= 

1.  1.  0.  1.  1.  1,  1.  1,  0.  1,  0,  0.  0.  1.  1.  1.  0.  1.  1.  0.  0.  0.  1  - 
Design  Spiral  Matrix[El. Disciplined 

1.  1.  0,  1,  1.  1.  1.  1.  0.  1.  0.  0.  0,  1.  1.  1.  0.  1.  1.  0.  0.  1,  1  - 
Design  Spiral  Matrix[E2.Discipline]= 

1.1.0.  1.  1,  1,  1.  1.  0.  1.  1,  0.  0,  1.  1.  1.  0.  1.  1.  0.  1,0,  1  ~ 
Design  Spiral  Matrix[Fl, Disciplined 

1.  1.  0,  0,  0,  0,  0.  0.  1,  1.  0.  0,  0.  1.  1.  1.  1.  1.  1.  1.  1.  1.  0 

~  Tasks/Tasks 

~  The  design  spiral  matrix  (aka  design  structure  matrix)  represents  the  \ 

first  order  input/output  requirements  associating  one  ship  design  \ 
discipline  to  another.. .a  value  of  "0"  indicates  the  discipline  is  not  an  \ 
input  to  the  given  element.  "1"  indicates  a  significant  level  of  input  to  \ 
the  element 


Min  Comp  Period[Phase.Disciplinel= 
0.5 

~  Month 

~  Minimum  period  of  time  required  to  complete  any  given  task  regardless  of 

the  resources  available  is  estimated  to  be  one  week  (same  for  all  tasks  \ 

and  all  phases) 


Average  Coord  Period[Phase.Discipline]= 
1 

~  Month 

~  For  tasks  requiring  coordination  and  personnel  interaction,  this  is  the  \ 

average  period  required  to  coordinate  a  task 


Feedback  Fraction  [Phase] = 
0.5 
~  Tasks/Tasks 
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